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Disclaimer 
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dorsement by  the  National  Institute  of  Standards  and  Technology,  nor  does  it  imply  that  the  items 
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Workshop  Overview 


The  NIST  Design  Repository  Workshop  was  aimed  at  understanding  the  needs  and  requirements 
for  the  development  of  large  scale  design  repositories  and  databases.  The  two-day  workshop  ad- 
dressed issues  associated  with  representation  and  indexing  schemes  to  facilitate  the  storage  and 
retrieval  of  data,  information,  and  knowledge  required  at  various  stages  of  the  design  process, 
such  as  design  rationale,  solid  model,  and  assembly  data.  Other  issues  discussed  included  data 
sharing,  collaborative  engineering,  interfaces,  the  role  of  the  Internet  in  this  research  area,  and 
critical  technology  gaps.  The  workshop  included  industry  case  studies,  as  well  as  overviews  of 
related  research  being  conducted  in  industry,  government,  and  universities. 


Note  from  the  Editors 


The  text  of  the  summaries  that  appear  in  this  volume  is  based  on  the  presentations  made  during  the 
workshop.  These  summaries  do  not  consist  of  a verbatim  transcript  of  the  workshop.  Rather, 
they  contain  a distillation  of  the  significant  points  of  each  presentation  and  the  discussions  that  fol- 
lowed. The  reader  should  not  attribute  any  direct  quotations  to  any  of  the  participants  in  the  work- 
shop on  the  basis  of  this  text. 
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Agenda 


Tuesday,  19  November,  1996 


8:00  am — 8:30  am:  Registration,  Coffee  and  Refreshments 

8:30  am — 9:00  am:  Welcoming  Remarks:  Dr.  Richard  Jackson,  Director,  MEL 

9:00  am — 9:30  am:  Overview  and  Goals  of  Workshop,  Ram  D.  Sriram 

9:30  am* — 10:45  am:  Presentation  Session  #1:  Industry  Needs 

Lalit  Chordia,  Thar  Designs 

Information  Needs  for  Pump  Design 
James  Michael,  Diebold  Inc. 

Information  Retrieval  During  Design  of  a Medication  Dispenser 

10:45  am — 11:00  am:  Break 

11:00  am — -12:30  pm:  Presentation  Session  #2:  Industry  Needs  (continued) 

Rich  Zarda,  Lockheed  Martin 

Development  of  an  Adaptive  Modeling  Language  (AML)  for 
Knowledge-Based  Engineering  with  Application  to  Interactive 
Gimbal  Design 
Tim  Malueg,  CRC 

MADE-IGD  Electro-Mechanical  Gimbal  Subcomponent  Database 
Carl  Izurieta,  Lockheed  Martin 

SAVE:  Simulation  Assessment  Validation  Environment 
D.  Navinchandra,  IndustryNet 

Product  Announcement  Clearinghouse:  From  the  Trenches 
Ed  Harter,  Boeing 

Integrated  Product  Data  Environment  (IPDE) 


12:30  pm — 1:30  pm: 
1:30  pm — 3:20  pm: 


3:20  pm — 3:30  pm: 


Lunch 

Presentation  Session  #3:  Industry  Needs  (continued) 

Gary  Coen,  Boeing 

Design  Data  Treatment  Issues  at  Boeing  Helicopters 
Wayne  Collier,  D.  H.  Brown  & Associates 

Seven  Proposed  Applications  of  Product  Data  Management 
Gene  Allen,  The  MacNeal-Schwendler  Corporation 
Use  of  Standards  for  Data  Storage  and  Exchange 
Kim  Cobb,  Lockheed  Martin 

Integrating  a Distributed,  Agile,  Virtual  Enterprise  in  the  TEAM 
Program 

Break 
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3:30  pm — 4:45  pm: 

Presentation  Session  #4:  Government  Programs 

Simon  Szykman,  NIST 

Engineering  Repository  Projects  at  NIST 

Michael  Case,  US-CERL 

Open  Collaborative  Engineering 

David  Thompson,  NASA  Ames  Research  Center 

Integrated  Design  Systems:  Aeronautics  Design  Process 

4:45  pm — 5:00  pm: 
5:00  pm — 6:00  pm: 

Improvement 

Break 

Presentation  Session  #5:  University  Research 

Yumi  Iwasaki,  Stanford  University 

Model-Based  Support  for  Collaborative  Engineering — Focus  on 
Ontologies:  How  Things  Work  Project 

Susan  Urban,  Arizona  State  University 

The  Shared  Design  Manager:  A Repository  for  Integrated 

Product  Data 

7:00  pm: 

Peter  Will,  USC-ISI 

Active  Catalogs:  A Designers  Aid 

Sham  Navathe,  Georgia  Institute  of  Technology 

Engineering  Design-Related  Database  Research  at  Georgia  Tech 

Dinner  at  Hotel 

8:00  am — 8:30  am: 
8:30  am — 10:00  am: 

Wednesday,  20  November,  1996 

Coffee  and  Refreshments 

Breakout  Sessions:  Current  Work,  Technology  Gaps  and 
R&D  Agenda 

Breakout  Session  1:  Industry  Perspective  (Chair:  Mike  Barbieri) 
Breakout  Session  2:  Database/Knowledge-Base  Frameworks 
(Chair:  Pradeep  Khosla) 

Breakout  Session  3:  Standards  for  Information  Modeling/Knowledge 
Representation  (Chairs:  Wayne  Collier  & Simon  Szykman) 

10:00  am — 10:15  am:  Coffee  Break 

10:15  am — 12:30  pm:  Presentation  Session  #5:  Government  Programs  (continued) 


12:30  pm — 1:30  pm: 
1:30  pm — 3:00  pm: 
3:00  pm: 

Kevin  Lyons,  DARPA 

Rapid  Design  Exploration  and  Optimization  (RaDEO) 

David  Gunning,  DARPA 

High-Performance  Knowledge  Bases  (HPKB) 

Sharon  Kemmerer,  NIST 

How  Does  a Standard  Become  a Standard? 

Lunch 

Summaries  of  Breakout  Sessions 

Workshop  Close 
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Glossary  of  Acronyms 


• AI:  Artificial  Intelligence 

• AML:  Adaptive  Modeling  Language 

• AMRF:  Automated  Manufacturing  Research  Facility 

• AP:  Application  Protocol 

• AP  203:  Configuration-Controlled  Design 

• AP  209:  Composite  and  Metallic  Structural  Analysis  and  Related  Design 

• API:  Application  Programming  Interface 

• ASIS:  American  Society  for  Information  Science 

• ASME:  American  Society  of  Mechanical  Engineers 

• ASTM:  American  Society  for  Testing  and  Materials 

• AW  ACS:  Airborne  Warning  And  Control  System 

• BAA:  Broad  Agency  Announcement 

• CAD:  Computer-Aided  Design 

• CAE:  Computer-Aided  Engineering 

• CAM:  Computer-Aided  Manufacturing 

• CATIA:  Computer  Aided  Three-dimensional  Interactive  Applications 

• CATIS:  Computer  Aided  Tactical  Information  System 

• CDME:  Collaborative  Design  Management  Environment 

• CD:  Committee  Draft 

• CD-ROM:  Compact  Disc — Read  Only  Memory 

• CERL:  Concurrent  Engineering  Research  Laboratory 

• CFD:  Computational  Fluid  Dynamics 

• CORBA:  Common  Object  Request  Broker  Architecture 

• COTS:  Commercial  Off-The-Shelf 

• DAI:  Data  Access  Interface 

• DARPA:  Defense  Advanced  Research  Projects  Agency 

• DAU:  Data  Access  Unit 

• DFM:  Design  For  Manufacture 

• DFx:  Design  For  “x” 

• DIS:  Draft  International  Standard 

• DoD:  Department  of  Defense 

• FDA:  Food  and  Drug  Administration 

• FDIS:  Final  Draft  International  Standard 

• FEA:  Finite  Element  Analysis 

• HIPED:  Heterogeneous  Intelligent  Processing  for  Engineering  Design 

• HPKB:  High-Performance  Knowledge  Bases 
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• HTML:  Hyper-Text  Mark-up  Language 

• HTTP:  Hyper-Text  Transfer  Protocol 

• 13:  Intelligent  Integration  of  Information 

• EBM:  International  Business  Machines 

• IDEF(O):  Integrated  Definition  Language 

• IEC:  International  Electrotechnical  Commission 

• IGD:  Interactive  Gimbal  Design 

• IGES:  Initial  Graphics  Exchange  System 

• IPDE:  Integrated  Product  Data  Environment 

• IS:  International  Standard 

• ISO:  International  Organization  for  Standardization 

• JCAHO:  Joint  Commission  on  the  Accreditation  of  Hospital  Organizations 

• JSF:  Joint  Strike  Fighter 

• MADE:  Manufacturing  Automation  and  Design  Engineering  (precursor  to  the  RaDEO  program) 

• MEL:  Manufacturing  Engineering  Laboratory 

• MIME:  Multipurpose  Internet  Mail  Extensions 

• MSC:  the  MacNeal-Schwendler  Corporation 

• NAMT:  National  Advanced  Manufacturing  Testbed 

• NASA:  National  Aeronautics  and  Space  Administration 

• NIIIP:  National  Industrial  Information  Infrastructure  Protocols 

• NIST:  National  Institute  of  Standards  and  Technology 

• NWI:  New  Work  Item 

• OEM:  Original  Equipment  Manufacturer 

• PC:  Personal  Computer 

• PDES:  Product  Data  Exchange  using  STEP 

• PDM:  Product  Data  Management 

• ProE:  ProEngineer 

• RaDEO:  Rapid  Design  Exploration  and  Optimization 

• RFQ:  Request  For  Quote 

• RRM:  Rapid  Response  Manufacturing 

• SAVE:  Simulation  Assessment  Validation  Environment 

• SC4:  ISO  Technical  Committee  184,  Subcommittee  4 

• SDM:  Shared  Data  Manager;  Shared  Design  Manager 

• STEP:  Standard  for  the  Exchange  of  Product  model  data 

• TEAM:  Technologies  Enabling  Agile  Manufacturing 

• UL:  Underwriters  Laboratory 

• USC:  University  of  Southern  California 

• VCU:  Version  Control  Unit 

• VLSI:  Very  Large-Scale  Integration 

• VRML:  Virtual  Reality  Modeling  Language 
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Presentation  Summaries 


Welcome  to  NIST 


Dr.  Richard  H.  F.  Jackson,  NIST  (jackson@cme.nist.gov) 
(20  slides  start  after  page  61) 


Dr.  Jackson  said  that  this  talk  was  one  of  his  more  pleasant  tasks:  welcoming  the  attendees, 
meeting  them,  and  learning  what  they’re  doing.  He  told  the  attendees  that  they  were  about  to  do  an 
important  thing,  that  is,  participate  in  a workshop.  This  will  help  NIST  learn  what  the  attendees 
need,  that  is,  industry’s  needs  for  measurement,  metrology,  and  standards.  Thus,  when  technol- 
ogy is  ready,  the  required  measurement,  metrology,  and  standards  should  be  in  place. 

Dr.  Jackson  said  that  NIST  was  the  only  national  research  laboratory  whose  specific  and  pri- 
mary mission  is  to  serve  U.S.  industry,  and  that  this  mission  had  been  substantiated  by  legislation. 
NIST  has  served  U.S.  industry  since  1901  as  the  National  Bureau  of  Standards,  and  since  1988  as 
the  National  Institute  of  Standards  and  Technology.  It  was  in  1988  that  the  government  added 
“assist  industry  in  the  development  of  technology  and  procedures”  to  NIST’s  mission.  Guest  re- 
searchers at  NIST — who  stay  from  a couple  of  weeks  to  a couple  of  years — are  one  means  of 
technology  transfer  to  industry. 

Dr.  Jackson  said  that  the  NIST  mission  was:  ‘To  promote  U.S.  economic  growth  by  working 
with  industry.”  He  pointed  out  that  “working  with  industry”  was  right  up  front  in  the  mission. 
Many  of  NIST’s  resources  support  this  mission. 

NIST  sponsors  four  main  programs:  the  Advanced  Technology  Program,  an  industry  re- 
search cost-sharing  program;  the  Manufacturing  Extension  Partnership  which  helps  small  and  me- 
dium-sized businesses  adopt  new  technology;  the  National  Quality  Program  which  administers  the 
Malcolm  Baldrige  National  Quality  Award;  and  the  NIST  Laboratories  which  focus  on  measure- 
ments and  standards,  including  standard  reference  databases. 

Manufacturing  research  occurs  in  some  form  in  all  of  NIST’s  laboratories.  The  Manufacturing 
Engineering  Laboratory  (MEL)  has  four  technical  divisions.  It  also  operates  the  Fabrication  Tech- 
nology Division,  also  known  as  “shops” — the  people  who  make  things  for  NIST.  MEL  serves 
primarily  the  mechanical,  discrete  parts  manufacturing  industry,  but  also  addresses  issues  that  cut 
across  all  manufacturing  industries. 

MEL  is  concerned  with  both  physical  and  informational  standards.  Physical  standards  for 
length  and  mass  are  derived  from  first  principles;  all  other  physical  standards  are  derived  from 
these.  Information  standards  for  interoperability  include  IGES  (Initial  Graphics  Exchange  Sys- 
tem), STEP  (Standard  for  the  Exchange  of  Product  model  data),  and  PDES  (Product  Data  Ex- 
change using  STEP).  MEL  considers  how  to  develop  and  disseminate  these  standards,  and  how  to 
provide  calibration  services  and  reports. 

MEL  is  organized  around  four  basic  programmatic  thrusts.  The  Manufacturing  Systems  Inte- 
gration thrust  is  working  toward  research  and  development  of  interoperability  standards  and  inte- 
gration technologies  for  the  implementation  of  virtual  manufacturing  enterprises.  The  Intelligent 
Machines  thrust  addresses  interface  standards  and  performance  measures  for  intelligent  control 
systems.  The  Manufacturing  Metrology  thrust  investigates  metrology  both  in  the  laboratory  and  in 
the  less-than-ideal  manufacturing  world.  The  Manufacturing  Processes  and  Equipment  thrust  is 
concerned  with  high-speed  high-precision  machines. 

Manufacturing  has  changed  radically  throughout  history.  When  industry  was  moving  from  a 
mass  production  paradigm  to  an  automation  paradigm  in  the  late  seventies  and  early  eighties,  NIST 
realized  that  it  had  to  change  its  programmatic  efforts  and  research  programs,  so  that  it  could  be 
ready  when  industry  moved  to  an  automation  paradigm.  So  NIST  built  the  Automated  Manufac- 
turing Research  Facility  (AMRF).  The  AMRF  project,  which  began  in  1980,  involved  the  tech- 
nology transfer  necessary  to  achieve  automation.  It  was  a completely  automated  manufacturing 
facility,  involving  both  computer-integrated  manufacturing  and  human-integrated  manufacturing. 

AMRF’ s accomplishments  include  contributions  to  IGES  and  PDES.  In  1996,  NIST  decided 
to  close  the  program,  because  automated  manufacturing  was  no  longer  a technology  of  the  future, 
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but  rather  a technology  of  the  present.  It  is  not  NIST’s  intention  to  compete  with  industry  (though 
if  a technology  is  commercializable,  to  promote  successful  commercialization  NIST  will  seek  to 
license  the  technology  to  industry;  thus  NIST  has  patented  technologies).  There  is  still  more  to  be 
done  in  automation:  machine  tool  controllers  can  be  automated,  and  systems  integration  is  also 
important. 

If  automated  manufacturing  is  the  present,  what  are  the  manufacturing  technologies  of  the  fu- 
ture? They  may  include  flexible  manufacturing,  agile  manufacturing,  rapid  manufacturing,  rapid 
prototyping,  and  niche  markets.  Dr.  Jackson  described  his  “What’s  Next  in  Manufacturing?”  slide 
as  “lots  of  concepts  and  buzzwords.”  He  summarized  it  by  saying  that  in  the  future,  there  would 
be  lean  organizations,  global  in  outlook,  distributed  in  operation,  and  agile  and  flexible  to  adapt  to 
customer  needs.  Information  technology  is  changing  what  we  do  and  how  we  operate.  Informa- 
tion-based manufacturing  is  a new  program  at  NIST.  It  used  to  be  that  the  primary  inputs  to  a 
manufacturing  process  were  capital,  material,  and  labor.  Now,  the  addition  of  information  tech- 
nology and  knowledge  have  become  essential. 

It  is  incumbent  on  MEL  to  address  issues  of  measurement  and  standards  for  information-based 
manufacturing.  Thus,  MEL  built  the  National  Advanced  Manufacturing  Testbed  (NAMT).  NAMT 
is  a showcase  for  the  future  of  manufacturing,  where  people,  computers,  and  software  are  net- 
worked. NAMT  addresses  standards  and  problems  in  automated  manufacturing.  NAMT  will  have 
connections  from  the  control  room  to  the  factory  floor.  These  connections  may  come  from  else- 
where in  NIST,  elsewhere  in  the  country,  or  in  the  world.  People  with  different  languages  and 
cultures  are  using  the  same  piece  of  software  to  address  problems,  and  will  sell  (or  already  have 
sold)  the  results. 

There  are  four  NAMT  start-up  projects  exploiting  information  technology.  The  Manufacturing 
Framework  program  involves  integration  of  manufacturing  systems,  and  the  development  of  a 
framework  for  standards  and  metrology.  The  Machine  Tool  Performance  Model  aims  at  a remote 
characterization  of  machine  tools.  Characterization,  Remote  Access,  and  Simulation  of  Hexapod 
Machines  involves  the  development  of  high-quality  simulation  models  for  manufacturing  processes 
and  machine  tools;  the  actual  performance  measurements  that  result  will  require  a large-scale  data 
repository. 

The  fourth  program  is  Nanomanufacturing  of  Atom-Based  Artifacts.  Atom-based  artifacts  are 
the  next  generation  of  artifact  standards,  or  “meter  sticks.”  Atom-based  artifacts  push  the  limits  of 
physics;  in  the  future,  standards  will  be  based  on  atomic  standards.  Standards  may  involve 
counting  atoms  across  line  widths.  Standard  artifacts  on  this  geometric  scale  are  affected  by  air; 
thus  these  artifacts  must  be  manufactured  and  must  exist  inside  a vacuum.  They  are  delivered  in- 
side a vacuum  suitcase  that  connects  to  a scanning  tunneling  microscope.  They  can  be  used  to 
calibrate  machine  tools  remotely,  across  the  street,  across  the  country,  perhaps  even  teleoperated 
from  NIST. 

One  of  NIST’s  services  to  industry  is  to  provide  high-quality  data  repositories.  The  goal  of 
this  workshop  is  to  investigate  technological  needs  for  the  design  of  such  repositories.  Such  re- 
positories must  consist  of  individual  assemblies  and  subassemblies,  and  might  capture  design  in- 
tent. Questions  to  answer  today  include:  Should  NIST  be  doing  something  to  support  large-scale 
design  repository  development?  Should  NIST  have  some  design  data  repository,  or  some  collec- 
tion of  problems  or  designs? 

Dr.  Jackson  finished  by  saying  that  he  saw  NIST  as  serving  its  customers.  He  reiterated  the 
objectives  of  the  workshop:  to  help  NIST  learn  industry’s  needs  for  measurement,  metrology,  and 
standards.  He  expressed  his  hope  that  it  would  be  a good  workshop. 
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Opening  Remarks  and  Introductions 

Dr.  Ram  Sriram,  NIST  (sriram@cme.nist.gov) 
(talk  given  without  slides) 


Dr.  Sriram  thanked  the  workshop  participants  for  coming.  He  described  them  as  falling  into 
four  classes  of  people:  designers,  researchers  supporting  infrastructure  for  designers,  university 
researchers  (who  advance  the  state  of  the  art),  and  government  employees  (who  help  industry 
through  the  development  of  new  technology  and  standards).  Part  of  the  goal  of  the  workshop  is  to 
gather  requirements.  Requirements-gathering  is  not  taught  in  academia. 

This  workshop  mixes  the  small-tool  industry  with  large  manufacturers.  Lots  of  information 
goes  into  the  design  process,  such  as  design  knowledge.  What  are  academia  and  industry  doing? 
They  are  working  at  the  conceptual  design  stage,  with  knowledge  and  constraints.  This  is  infor- 
mation-rich. 

The  workshop  objectives  include  industry  case  studies.  The  industry  participants  vary  widely. 
For  instance.  Dr.  Chordia  works  for  a small  business  of  twelve  people,  whose  experience  is  with 
AutoCAD;  small  businesses  are  a large  part  of  the  United  States  manufacturing  base.  Diebold,  Inc. 
is  a company  with  five  thousand  people.  They  have  design  experience  with  paper  handling  and 
cash  machines,  and  a division  of  about  thirty  people  working  on  design  of  medication  dispensers. 

The  workshop  objectives  also  include  roadmaps  for  research,  from  industry  issues,  to  funda- 
mental research  issues,  to  standards.  At  first  in  the  workshop  we  will  discuss  the  state  of  the  art, 
and  then  discuss  the  technology  gaps,  which  will  lead  to  a research  and  development  agenda. 
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Information  Needs  for  Pump  Design 

Dr.  Lalit  Chordia,  Thar  Designs  (chordia@thardesigns.com) 
(14  slides  start  after  page  82) 


Dr.  Chordia  started  his  talk  by  emphasizing  that  he  was  discussing  the  needs  of  a small  busi- 
ness. The  needs  of  small  businesses  are  different  from  those  of  a large  company. 

Let’s  consider  day-to-day  design.  Dr.  Chordia’ s case  study  is  high-pressure  fluid  pump  de- 
sign. Such  small  specialty  manufacturing  makes  up  the  bulk  of  US  industry.  These  pumps  must 
withstand  up  to  ten  thousand  pounds  of  pressure.  A pump  might  be  designed  to  combine  two  sub- 
stances. For  example,  the  combination  of  coffee  with  carbon  dioxide  results  in  decaffeinated  cof- 
fee and  caffeine  by  supercritical  fluid  extraction.  Hops  can  similarly  be  extracted  from  beer.  Re- 
strictions on  available  space  place  strict  constraints  on  viscosity  and  polymerization.  Cleaning  is 
also  important;  machine  parts  are  cleaned  with  supercritical  carbon  dioxide.  It  takes  830  to  10,000 
pounds  of  pressure  to  compress  liquid  carbon  dioxide.  Although  pumps  are  a very  old  idea,  there 
is  very  little  information  in  the  literature  on  carbon  dioxide  pumping. 

Why  did  a small  company  among  many  pump  manufacturers  in  the  market  decide  to  design  one 
for  liquid  carbon  dioxide?  Existing  pumps  did  not  work  well  for  high-pressure  applications. 
Other  pumps  were  designed  for  liquids,  which  are  incompressible.  Carbon  dioxide  is  compressi- 
ble; the  dead  volume  is  important.  Ignoring  the  dead  volume  leads  to  inefficiency. 

During  design,  we  need  to  compensate  for  heat.  This  leads  to  cooling  requirements.  Cost- 
efficiency  is  also  important;  in  order  to  be  successful,  a superior  design  would  preferably  also  be 
lower  in  cost  than  what’s  available  in  the  market. 

A chart  from  Stanford  University  relates  the  volume  inside  pump  heads  to  density,  pressure, 
and  temperature.  This  allows  us  to  simulate  what  is  inside  the  pumps.  How  tight  should  we  keep 
tolerance  to  minimize  dead  volume?  What  manufacturing  processes  are  required?  How  do  we 
assemble  pumps?  Bearings  allow  us  to  maintain  alignment  and  minimize  dead  volume.  Stronger 
materials  expand  less,  and  expansion  adds  dead  volume.  Reducing  heat  generation  is  important 
because  hot  fluid  is  less  dense,  and  therefore  less  efficient.  Stainless  steel  pumps  have  a high  fric- 
tional coefficient.  Sapphire  has  a low  frictional  coefficient  and  high  thermal  conductivity;  sapphire 
is  better  than  ceramics,  but  more  expensive  as  well.  Making  decisions  on  material  requires  not  just 
mechanical  engineers,  but  all  engineering  disciplines. 

We  believe,  in  general,  that  smaller  is  cheaper.  A smaller  pump  head  is  a less  expensive  pump 
head.  More  critically,  a smaller  design  has  less  stroke  volume,  which  means  that  it  requires  more 
speed,  which  increases  the  friction;  but  the  friction  needs  to  be  kept  low.  This  is  not  an  O-ring 
design.  It  is  a C-channel  design  with  a self-sealing  ring  inside  it.  The  force  on  the  piston  is  opti- 
mized by  the  force  generated  by  the  liquid  itself.  Strong  material  allows  us  to  reduce  length  and 
diameters. 

Because  we  are  a small  company,  we  need  to  bootstrap  everything.  Our  concept  formulation 
asks:  what’s  available?  what’s  not  working?  what  do  we  need  to  do?  The  design  of  the  chassis 
that  holds  the  pump,  and  not  the  pump  itself,  was  the  most  difficult  problem.  The  final  product 
was  half  the  price  of  any  competitors.  It  was  scalable:  it  could  pump  forty  ml/min,  or  forty  thou- 
sand ml/min. 

How  could  we  have  done  better?  We  could  have  had  rapid  access  to  information:  what’s  out 
there?  what’s  not?  what’s  good  and  bad  about  what’s  out  there?  what  other  pumps  exist?  how  do 
people  reduce  friction?  Perhaps  we  could  have  adapted  someone  else’s  design.  We  could  have 
had  finite  element  analysis  to  help  us  with  the  design. 

The  most  important  small  business  issue  is  that  there  are  so  many  different  kinds  of  technology 
and  information.  We  need  skilled  labor  and  we  need  more  of  it  every  year.  We  get  mechanical 
engineers  who  don’t  know  AutoCAD;  we  encourage  them  to  learn  it  via  the  Internet.  Our  future 
information  requirements  are  many.  We  need  access  to  information  and  tools.  We  need  a design 
concepts  database:  we’d  like  to  be  able  to  use  a motor  from  some  other  company  in  our  design  by 
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means  of  a “drag-and-drop”  operation.  Should  such  a database  be  on  the  Internet  or  on  CD-ROM? 
Few  small  companies  have  PCs  (Personal  Computers)  with  a CD-ROM  on  everybody’s  desk.  We 
can  design  faster,  better,  and  more  competitively  if  such  a database  is  on  the  World  Wide  Web. 

A question-and-answer  period  followed  Dr.  Chordia’s  talk.  Questioners  are  identified  by 
number. 

Ql:  You  went  from  a traditional  design  to  a high  speed  pump  with  a small  footprint.  What 
happened  to  the  lifetime  of  the  pump. 

A:  It  increased. 

Ql:  Do  you  have  a baseline  for  that? 

A:  No,  but  we  have  a customer  who’s  been  using  one  for  two  years. 

Q2:  Would  you  want  your  access  to  design  concepts  to  be  via  text  or  pictures? 

A:  Graphical  or  video. 

Q2:  It  seems  you  would  not  want  an  exact  solid  model,  but  rather  a vague  description. 

A:  Exactly. 

Q3:  What  would  you  want  in  a design  concept  versus  what  it  takes  to  get  a patent? 

A:  That’s  a tough  question.  We  don’t  want  a product  patent;  we  want  a concept  patent. 

Q3:  Would  such  a patent  application  be  too  detailed? 

A:  Yes. 

Q4:  It  took  you  six  months  to  come  up  with  a prototype.  How  long  would  it  have  taken  if  you 
had  better  information? 

A:  It  took  us  six  months  to  come  up  with  a product  and  to  work  out  the  bugs.  This  would 
drop  to  three  to  four  months  with  better  information  access  and  management. 

Q5:  How  many  prototypes  did  you  need?  Did  you  use  ceramics  in  the  prototype  head  or  in  the 
product  head? 

A:  We  needed  two  prototypes.  Our  head  is  a mix  of  ceramic  and  sapphire.  A ceramic-coated 
steel  piston  was  not  as  effective  as  we  had  hoped. 

Q6:  What  information  resources  did  you  use? 

A:  Magazines  called  Design  Yields,  Machine  Design,  and  Design  Facts.  We  checked  a Ther- 
mos Catalog  to  see  what  pumps  were  available. 

Q7:  What  information  technology  tools  did  you  use. 

A:  Absolutely  none.  We  would  have  liked  to  use  some. 

Q8:  What  variables  are  most  important  for  a small  business? 

A:  Skill  levels. 

Q8:  How  about  cost  of  tools? 

A:  That’s  important  too.  We  use  AutoCAD  Lite.  There’s  not  enough  work  to  justify  spending 
$3,000  for  AutoCAD 

Q9:  What  do  you  budget  each  year  for  hardware  and  software  training? 

A:  We  do  it  on  the  fly. 

Q9:  How  much  did  you  spend  last  year? 

A:  $12,000. 

Q9:  What  capabilities  did  the  training  add? 

A:  In  a small  business,  the  squeaky  wheel  gets  the  grease. 
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Information  Retrieval  During  Design  of  a Medication  Dispenser 

James  Michael,  Diebold,  Inc. 

(11  slides  start  after  page  97) 


Mr.  Michael  introduced  himself  as  a mechanical  development  engineer  with  Diebold,  Inc.  in  its 
MedSelect  Systems  division.  He  has  been  with  Diebold  for  a couple  of  years.  Previously  he 
worked  with  high-speed  paper  systems.  He  built  his  first  design  with  Lego  blocks  when  he  was 
five  years  old. 

People  know  Diebold  as  a manufacturer  of  automatic  teller  machines,  or  for  physical  and  elec- 
tronic security  systems.  We  also  work  in  information  systems,  material  management,  and  billing. 
This  talk  focused  on  the  design  of  a medication  dispenser  called  a Unit  Dose  Module.  During  this 
design,  there  was  information  that  was  difficult  to  access  during  product  development. 

A hospital  network  has  a database  that  includes  data  such  as  patient  information.  Each  dis- 
pensing station  has  a computer.  A nurse  or  doctor  picks  a patient  and  a medication,  and  the  medi- 
cation is  then  dispensed.  The  medication  dispenser  is  similar  to  an  electronically  controlled  chest 
of  drawers.  The  Unit  Dose  Module  is  two  feet  high.  It  keeps  medications  under  lock  and  key.  It 
uses  helix  dispensing  for  tablets  and  capsules,  and  gated  dispensing  for  vials  and  ampules.  The 
medication  drops  off  shelves  into  the  chute  at  the  bottom.  You  ask  for  exactly  one  dose  and  you 
get  exactly  one  dose. 

The  Product  Development  Cycle  slide  shows  a simplified  version  of  the  product  development 
cycle.  Information  requirements  included  product  requirements,  competitive  analysis,  industry 
standards,  and  legislation.  We  obtained  these  information  requirements  through  customers,  mar- 
keting, patents,  libraries,  the  World  Wide  Web,  and  competitive  literature.  We  would  have  also 
liked  to  obtain  these  requirements  through  competitive  products,  information  consolidation,  and 
resource  links. 

The  initial  concept  of  development  assumes  that  engineering  is  more  heavily  involved.  We 
have  obtained  a marketing  requirements  specification  and  are  now  producing  a functional  require- 
ments specification.  We  have  a concept  of  what  a solution  is,  but  we  need  to  do  a technology 
search  and  test  our  solution. 

We  look  into  standards  such  as  JCAHO  (Joint  Commission  on  the  Accreditation  of  Hospital 
Organizations),  a hospital  standard,  and  ASIS  (American  Society  for  Information  Science),  a secu- 
rity standard.  We  found  state  regulations  hard  to  obtain.  Our  questions  included:  what  are  the 
state  regulations?  how  are  they  applicable?  We  read  magazines  such  as  Machine  Design,  as  well  as 
magazines  from  the  ASME.  We  checked  with  medication  suppliers  to  understand  all  the  variables 
(including  sizes,  weight  and  weight  distribution,  material,  and  frequency  of  use),  and  their  vari- 
ability. Frequency  of  use  is  important:  why  design  for  medication  that  is  rarely  or  never  used? 

The  security  of  the  locked  cabinet  is  electronically  accessed.  To  restock,  someone  must  log  in. 
But  we  also  need  a manual  key  override,  for  power  failures  and  the  like.  Should  the  manual  key 
override  have  one  lock?  Two  locks?  What  are  the  relevant  regulations? 

A workshop  participant  asked  if  anybody  at  his  company  was  developing  advisory  systems  to 
aid  in  the  design  process.  Mr.  Michael  answered  that  nobody  was  developing  such  systems;  in- 
formation requirements  were  simply  being  fulfilled,  one  design  at  a time. 

“DFx”  refers  to  “Design  For  something”:  design  for  assembly,  manufacturability,  environ- 
ment, disassembly,  cost,  or  even  design  for  environment  though  fewer  people  are  familiar  with  the 
latter.  In  our  design,  do  we  need  to  design  a new  part,  or  can  we  use  outside  manufacturing 
through  an  original  equipment  manufacturer  (OEM)?  Is  there  an  available  supplier?  We  also  sat- 
isfy some  information  requirements  by  ourselves,  with  information  scribbled  in  notebooks  and 
binders.  We  used  TelTech,  a technical  knowledge  service.  Larger  corporations  have  standards, 
such  as  UL  (Underwriters  Laboratory)  standards  for  safety  packaging.  One  of  our  OEM  supplier 
resources,  Thomas  Register,  recently  went  on-line. 
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We  used  CAD/CAE  (Computer-Aided  Design/Computer-Aided  Engineering)  databases.  Die- 
bold  is  moving  to  a CAD  package  with  better  information  storing  capabilities.  Our  PDM  (Product 
Data  Management)  involves  processes,  building  materials,  and  drawings.  In  the  future,  we  see 
CAE-PDM  integration. 

Information  access  was  accomplished  via  common  access  methods,  such  as  the  World  Wide 
Web.  Imagine  a software  package  or  a web  site.  On  the  “Information  Consolidation/Resource 
Links”  slide,  below  each  phase  of  the  development  cycle  is  listed  the  relevant  requirements.  There 
are  a large  number  of  resources.  We  want  appropriate  links  from  requirements  into  the  pool  of 
information.  We  want  links  to  private  information,  such  as  corporate  standards.  This  information 
would  not  be  available  to  the  rest  of  the  world.  We  also  want  links  to  personal  information:  “my” 
experience,  and  my  associates’  experience.  This  information  also  would  not  be  available  to  the  rest 
of  the  world. 

Perhaps  the  software  could  have  reminders  that  asked  the  user:  “what  about  your  experience?” 
or  suggested:  “check  the  corporate  standards”.  Better  yet,  the  software  could  allow  the  user  to 
personalize  the  interface.  Such  personalization  might  include  “bookmarks”  or  “notes.”  What 
would  this  offer  the  designer?  It  offers  structure,  a checklist  for  the  cycle,  and  appropriate  access 
that  allows  customization. 

A question-and-answer  period  followed  Mr.  Michael’s  talk.  Questioners  are  identified  by 
number. 

Ql:  What  is  better  about  the  new  CAD  package  you’ll  be  using? 

A:  It  has  a better  solid  modeler,  and  it  enhances  concurrent  development  with  better  communi- 
cation and  better  conveyance  of  information.  One  can  store  preferred  components  in  the  CAD 
package. 

Q2:  How  do  you  retrain  “People  Who  Draw”  to  turn  them  into  “solid  modelers”? 

A:  We  all  currently  use  the  CAD  system.  Some  use  the  solid  modeler.  We  would  introduce 
some  sort  of  training  program.  There  are  always  some  stragglers. 

Q3:  Our  engineers  get  70%  of  their  information  from  their  colleagues.  Is  your  experience 
similar? 

A:  Yes.  Your  associates  are  right  there.  We  are  not  trying  to  get  away  from  that;  we  just  want 
other  resources  to  be  accessible. 

Q3:  What  percent  of  your  product  is  made  by  outside  vendors?  How  much  is  off-the-shelf 
and  how  much  is  made-to-order?  Do  you  as  an  engineer  interact  with  vendors,  or  do  you  get  pur- 
chasers to  do  it  based  on  specifications  that  you  provide. 

A:  We  have  no  OEM  design  team.  Rather,  we  use  OEM  components.  They  are  a significant 
percentage.  We  use  a standard  part  when  possible  because  it’s  cheaper. 

Q4:  What  percent  of  the  cost  is  used  to  buy  things  that  you  don’t  manufacture? 

A:  It  varies  from  product  to  product.  With  the  Unit  Does  Module,  it  is  approximately  15%. 

Q5:  Do  you  have  a library  of  suppliers’  parts?  Do  they  provide  you  with  this  information? 

A:  We  created  our  own  list  of  preferred  tools. 

Q6:  How  often  do  you  create  a new  dispenser?  What  are  the  new  requirements? 

A:  Typically  we  create  new  types  of  dispensers.  The  requirements  include  industry  require- 
ments and  hospital  requirements  for  the  Unit  Dose  Module.  We  generally  use  a modification  of  an 
existing  solution.  Development  is  an  ongoing  activity. 
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Development  of  an  Adaptive  Modeling  Language  for  Knowledge- 
Based  Engineering  with  Application  to  Interactive  Gimbal  Design 

Dr.  Rich  Zarda,  Lockheed  Martin  (zarda@slr.orl.mmc.com) 

(16  slides  start  after  page  104) 


Dr.  Sriram  said  that  the  first  set  of  talks  had  been  given  by  people  who  were  designers.  The 
second  set  of  talks  concerned  how  people  in  industry  support,  or  plan  to  support,  designers  such 
as  Dr.  Chordia  and  Mr.  Michael.  Dr.  Sriram  requested  that  there  be  no  questions  in  the  series  of 
three  Lockheed-Martin-related  talks  until  the  end,  and  introduced  Dr.  Zarda. 

Dr.  Zarda  discussed  the  automation  of  the  gimbal  design  process.  A gimbal  is  similar  to  your 
head  in  that  it  has  rotational  degrees  of  freedom  that  correspond  to  a “neck”  and  “eyes”.  The  most 
complicated  Lockheed-Martin  domain  is  the  Apache  Helicopter  Gimbal.  It  takes  twelve  people 
nine  months  to  design,  and  includes  optical  capabilities,  mechanical  capabilities,  servo  guides, 
thermodynamic  analysis,  and  missiles.  The  investment  into  the  development  of  an  Adaptive  Mod- 
eling Language  (AML)  for  knowledge-based  engineering  with  application  to  Interactive  Gimbal 
Design  (IGD)  has  significant  impact  on  gimbal  design.  Indeed,  it  has  significant  impact  on  all  pro- 
grams. 

On  the  “Metrics  for  Impact  and  Progress”  slide,  Design  1 was  created  “from  scratch”.  It  took 
about  8,634  hours  to  create.  Design  2 was  created  from  Design  1,  but  it  still  took  about  7,000 
hours  to  create,  even  though  there  were  no  hours  spent  for  the  servo,  rather  than  1,383.  (Note  that 
these  are  not  actual  figures — the  time  requirements  have  all  been  multiplied  by  a constant  factor  in 
order  to  protect  proprietary  information.  Since  the  constant  was  the  same  for  all  figures,  the  ratios 
of  times  are  correct.) 

AML  drives  Pro/E,  M-Vision,  ManufacturingSoft,  and  many  other  products.  The  objective  of 
the  program  is  to  develop  and  enhance  AML.  Then,  we  apply  AML  to  our  IGD  system,  and  create 
a gimbal  database  with  the  intent  of  reducing  design  and  redesign  times.  There  are  many  require- 
ments in  an  IGD  system.  There  is  also  a material  database,  and  there  are  many  processes.  We 
want  to  be  able  to  save  a gimbal  design.  No  two  gimbals  are  the  same;  this  creates  a nightmare  for 
packaging. 

Our  program  has  accomplished  several  milestones.  We  had  our  kick-off  meeting.  We  cap- 
tured knowledge  from  the  conceptual  design  process  for  optical  design,  and  created  a precision 
design  product.  Our  optical  simulation  is  now  complete.  We  are  developing  a direct  interface  be- 
tween Pro/E  and  AML.  We  would  like  to  go  through  STEP  (Standard  for  the  Exchange  of  Product 
model  data),  but  STEP  is  not  available.  We  want  an  intelligent  STEP  database,  and  we  want  STEP 
to  be  an  official  standard  as  soon  as  possible. 

The  human  head  is  a five-axis  gimbal.  More  typically,  we  work  with  a two-axis  gimbal.  Most 
communication  in  the  design  process  is  word-of-mouth,  not  automated.  The  problem  is  that  we 
pick  a Pro/E  product  to  make  things,  but  it  won’t  make  gimbals.  DARPA  (Defense  Advanced  Re- 
search Projects  Agency)  and  DoD  (the  Department  of  Defense)  say  that  we  have  to  cut  costs  by 
50%,  which  means  that  we  have  to  change  everything. 

What  could  help  us?  A mature  STEP  definition.  A three-dimensional  automated  packing  algo- 
rithm; it’s  easy  to  put  a two-dimensional  puzzle  together,  but  products  aren’t  two-dimensional — we 
need  three  dimensions!  Electrical  components  are  two-and-a-half-dimensional,  and  mechanical 
components  are  three-dimensional,  which  is  why  electrical  design  is  ahead  of  mechanical  design. 
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MADE-IGD  Electro-Mechanical  Gimbal  Subcomponent  Database 

Dr.  Tim  Malueg,  CRC  (tmalueg@hsv.crc.com) 

(11  slides  start  after  page  121) 


Dr.  Malueg  wants  to  capture  data — not  intelligent  data,  but  performance  data.  Then,  we  can 
automate  selection  of  particular  components  based  on  performance  criteria. 

Conceptual  geometry  involves  a grammar  for  a fundamental  three-dimensional  model.  Such  a 
grammar  includes  primitives,  such  as  a block  and  a cone.  It  should  do  interference  checking. 
There  are  several  benefits  of  such  technology.  Many  components  are  not  used  as-is;  we  need  to 
standardize  the  selection  of  components.  We  need  to  use  a database  to  expand  the  availability  of 
searchable  subcomponent  manufacturers.  We  need  to  assist  in  the  identification  and  resolution  of 
standards  by  talking  to  different  suppliers  of  data,  and  establishing  standards  for  characteristics. 
We  anticipate  vendor  support  through  limited  access  to  vendor  databases.  A flexible,  dynamic 
architecture  should  support  ad-hoc  queries,  and  create  new  attributes. 

In  our  system  network  design,  proprietary  designs  are  input  and  stay  at  the  facility  where  they 
are  proprietary.  They  stay  behind  a firewall.  Our  system  architecture  includes  three  interfaces  to 
the  Oracle  database.  Our  replication  process  replicates  the  magnitude  of  data  to  our  facility. 

Consider  bearing  data.  Compliance  is  the  reciprocal  of  stiffness.  We  plan  embedded  applets 
and  Java  routines.  We  plan  for  tables  in  our  architecture.  We  intend  to  dynamically  generate  tables 
on-the-fly  with  indices  that  expedite  the  performance  of  queries. 

Important  issues  include  speed  versus  flexibility.  A relational  database  is  fast,  but  it’s  static. 
Our  focus  is  totally  dedicated  to  gimbal  subcomponents  and  engineers’  processes.  Should  units  be 
vendor-specific  or  standard? 
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SAVE:  Simulation  Assessment  Validation  Environment 

Carl  Izurieta,  Lockheed  Martin  (izzy@mar.lmco.com) 

(9  slides  start  after  page  133) 


Mr.  Izurieta  started  by  summarizing  the  SAVE  (Simulation  Assessment  Validation  Environ- 
ment) program.  SAVE  integrates  modeling  and  simulation  tools  into  the  environment.  All  of  these 
tools  are  commercial,  off-the-shelf  tools;  none  are  homegrown.  They  include  the  CATIA  (Com- 
puter Aided  Three-dimensional  Interactive  Applications)  CAD  system,  as  well  as  emerging  tech- 
nologies from  DARPA  programs. 

We  are  validating  die  environment  on  the  F-16  and  F-22.  This  eight-million-dollar  project 
started  April  1995.  We  want  the  program  to  be  in  place  in  approximately  the  year  2000. 

We  want  to  simulate,  cutting  metal,  rather  than  actually  doing  it.  We  are  frying  to  make  a plug- 
and-play  simulation  of  the  factory  from  Deneb  Robotics.  We  want  implementation  and  best  prac- 
tices: there  is  much  technology  being  integrated  in  the  current  design  process,  so  we  can’t  do  the 
design  process  in  the  same  way  we  did  it  in  the  past.  The  benefits  of  SAVE  for  JSF  (Joint  Strike 
Fighter)  were  about  2%,  1.97%  to  be  precise.  But  for  about  three  thousand  aircraft,  about  2%  is 
several  billion  dollars  in  savings. 

The  SAVE  team  brings  expertise  and  experience  to  the  problem.  The  SAVE  program  is  man- 
aged in  Marietta,  Georgia.  There  are  checks  and  balances  in  place  for  performance  of  the  contract. 
The  operational  task  force  makes  suggestions  about  what  are  right  ideas  and  wrong  ideas.  The 
advisory  board  evaluates  the  suggestions. 

This  year  we  demonstrated  the  product  at  the  defense  manufacturers  conference.  The  F-16  was 
redesigned  for  a horizontal  tail  in  the  mid-eighties.  We  used  this  redesign  as  a baseline;  we  vali- 
dated our  tools  on  that  redesign — the  system  produced  a similar  redesign  decision.  The  next  phase 
is  the  development  of  a relational  database  interface.  The  interim  demonstration,  which  will  be 
given  in  February  1998,  will  include  engine  inlets.  The  final  demonstration  will  be  given  at  the  end 
of  1999. 


20 


Product  Announcement  Clearinghouse:  From  the  Trenches 

Dr.  D.  Navinchandra,  IndustryNet  (dchandra@cs.cmu.edu) 

(slides  unavailable) 


Dr.  Navinchandra  started  his  talk  by  saying  that  engineering  design  and  the  business  process 
are  transforming  the  buying  and  selling  process.  This  led  to  the  idea  of  using  design  repositories. 
Dr.  Navinchandra  first  became  interested  in  this  idea  in  1983  while  working  for  a design  engineer, 
doing  engineering  based  on  precedents.  Say  we  are  trying  to  build  on  something  that  already  ex- 
ists, i.e.,  not  “clean-sheet”  design.  How  do  we  represent  designs?  Money  has  poured  into  this 
problem  for  ten  years. 

Dr.  Navinchandra  became  involved  with  IndustryNet  to  supply  information  needs  for  engi- 
neers. He  was  studying  the  control  of  metal-working  materials,  and  manufacturing  rules.  He 
joined  the  company  to  make  things  happen  in  the  real  world.  IndustryNet  is  one  of  the  few  com- 
panies that  have  tried  to  bring  large  design  repositories  on-line  in  a real-world  area.  There  are  hard 
issues,  but  an  engineer’s  short-term  needs  don’t  require  new  research.  Too  much  new  research  is 
rehashing  of  old  work. 

What  do  engineers  require  in  the  short  term?  What  is  important  to  survive  in  a real  environ- 
ment? The  relationship  between  the  specifying  engineer  and  the  prototypers  is  important.  What  is 
an  OEM?  How  does  a design  engineer  exist  in  the  process  with  vendors  and  the  costing  depart- 
ment? A study  from  the  automotive  manufacturing  industry  revealed  that  2%  to  10%  of  the  cost  of 
a product  was  involved  in  buying.  10%  to  40%  was  involved  in  selling.  That  left  about  60%  for 
the  intrinsic  value  of  the  product. 

Information  liquidity  is  important.  How  do  we  provide  intelligent  catalogs?  How  do  we  pro- 
vide information  on  day-to-day  deliverables?  Fancy  finite  element  analysis  systems  are  fine,  but 
they  are  only  a small  part  of  the  process.  We  need  to  integrate  the  decision-making  process 
throughout  the  organization,  not  just  with  the  engineer.  A day  in  the  life  of  a design  engineer  is 
our  area  of  interest.  We  are  trying  to  understand  where  the  maximum  percentage  of  the  total  value 
of  the  product  is  determined  during  the  design  phase.  In  business-to-business  transac- 
tions— “sourcing” — most  of  the  cost  is  during  the  design  phase. 

In  automotive  manufacturing,  workers  on  the  production  line  can  perform  multi-modal 
searches  on  catalogs.  They  search  on  part  number,  attribute,  function,  name,  or  application.  They 
are  trying  to  make  an  internal  catalog  standard  into  a national  standard.  Supplier  database  connec- 
tion is  not  glamorous  work,  nor  is  ordering  through  central  purchasing.  Thus  work  must  be  recog- 
nized as  valuable  by  the  entire  company.  Each  piece  must  be  recognized  as  useful  and  optimized; 
integration  is  difficult. 

One  can  locate  vendors,  searching  by  functionality,  materials,  or  cost,  and  evaluate  them.  In 
the  selection  process,  one  needs  to  look  at  the  catalog  itself.  Then  comes  the  sourcing  step:  “where 
do  I get  it?” — the  biggest  value  is  determined  during  this  step.  Next,  one  creates,  sends,  and  ful- 
fills the  order — less  value  is  determined  here.  Then  support  assessment,  which  determines  more 
value  again.  The  whole  transaction  “wraps  around”. 

In  a long-running  business-to-business  transaction,  the  sourcing  step  involves  locating  and 
evaluating  suppliers.  No  longer  do  design  engineers  give  specifications  for  someone  else  to  place 
the  orders;  they  place  the  orders  themselves.  We  are  dealing  with  automated  negotiation  via  intelli- 
gent agents  (details  of  which  are  outside  the  scope  of  this  workshop).  In  general,  commerce  oc- 
curs on  private  channels.  It  occurs  on  intranets  and  private  networks,  not  on  the  web.  This  is  not 
good,  but  it  is  a reality. 

Interactive  content  architectures,  such  as  product  announcement  clearinghouses,  are  a basic 
type  of  business-to-business  technology  platform.  We’ve  been  beta-testing  such  a product  an- 
nouncement clearinghouse  for  a couple  of  months.  Suppose  you  read  trade  magazines,  see  prod- 
uct announcements,  clip  and  file  them  in  an  unindexed  manner.  Our  goal  is  to  automate  that  proc- 
ess with  automatic  notification,  by  fax,  of  product  announcements.  Fax  is  what  engineers  very 
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often  want,  though  we’ll  support  email  as  well.  There  is  a lot  of  mundane  work  involved.  Dozens 
of  people  in  a room  develop  an  ontology  for  automatic  classification  of  these  products.  Those  in- 
terested in  demonstration  systems  can  contact  Dr.  Navinchandra. 

We  are  testing  agent  architectures  to  provide  information  to  design  engineers.  We  want  a stan- 
dard common  architecture  for  catalog  information.  We  might  develop  a variety  of  different  search 
methods:  name,  keyword,  natural  language,  parametric,  application-based,  and  function-based. 
Methods  appearing  earlier  in  that  list  are  easier  to  achieve  but  less  useful.  The  problem  with  para- 
metric searching  is  twofold:  getting  data  in  the  system,  and  normalizing  it.  For  example,  a drill  bit 
consists  of  section  for  clamping  the  bit,  and  the  cutting  portion  of  the  bit;  some  say  the  length  of  a 
bit  is  just  the  length  of  the  cutting  part,  while  others  include  the  clamping  portion  in  the  length. 

We  need  to  carry  cost  information,  but  cost  information  is  different  for  different  companies. 
We  would  love  to  have  an  algorithm  that  can  take  a table  in  a catalog  and  interpret  it.  Several 
Ph.D.  dissertations  can  be  written  in  the  area  of  “table  understanding”.  Alas,  this  area  of  research 
is  not  “sexy”. 

Unlocking  information  is  the  knowledge  engineering  bottleneck.  One  needs  to  get  data  into  the 
system.  We  found  out  in  focus  groups  that  we  lose  the  customer  if  we  don’t  produce  the  answer 
to  a query  quickly.  There  are  massive  amounts  of  information  flowing  into  the  system.  We  are 
preparing  a paper-to-electronic  conversion  by  retyping  the  paper  and  representing  it  with  some 
strange  version  of  the  interleaf  format.  We  want  unskilled  laborers  to  take  the  information  and  put 
it  in  the  system  cheaply.  We  are  distributing  the  data  entry  tasks  around  the  world.  We  want  to 
automatically  publish  databases  in  whatever  form  is  required. 

To  summarize  the  transformation  of  buying  and  selling  relationships:  The  design  engineer  is 
important  to  the  cost  of  the  product. 

A question-and- answer  period  followed  Dr.  Navinchandra’ s talk.  Questioners  are  identified  by 
number. 

Q1:  You’re  not  authoring  information,  but  rather  reprocessing  it.  How  do  you  deal  with  the 
copyright  issues? 

A:  In  two  ways.  First,  we  are  reprocessing  information  on  behalf  of  the  ASME  (American 
Society  of  Mechanical  Engineers).  They  allow  us  to  provide  the  information. 

Ql:  What  if  there’s  a mistake?  Somebody  uses  your  system  and  loses  a million  dollars. 
Who’s  responsible? 

A:  I don’t  know.  The  second  way  is  private  channels:  intranets.  We  take  responsibility  for 
mistakes  there,  with  a cap  on  the  costs. 

Ql:  Do  you  have  technical  information? 

A:  Talk  to  me  off-line. 

Q2:  Who  are  the  customers?  What  is  your  business  model? 

A:  We  have  2500  free  registered  users.  The  system  is  an  advertiser-paid  model  where  the 
money  comes  from  companies,  sellers,  who  put  their  information  on  line. 
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Integrated  Product  Data  Environment  (IPDE) 

Dr.  Ed  Harter,  Boeing  (edward.d.harter@boeing.com) 
(39  slides  start  after  page  143) 


Dr.  Harter  asked  the  attendees  to  refer  back  to  Dr.  Jackson’s  remarks.  One  purpose  of  the 
workshop  is  for  industry  to  communicate  its  needs.  What  are  Boeing’s  needs  and  interests? 

Dr.  Harter’s  group,  Boeing  Defense  and  Space  Group  engineering  provides  computer  support. 
The  immediate  issue  is  pressure  to  bring  development  costs  down  while  increasing  performance. 
Consider  design  analysis  and  engineering  applications  (e.g.,  aerodynamic  analysis,  with  static 
stress,  dynamic  stress,  infrared  signatures,  cross-sections,  and  so  on).  This  analysis  is  informal 
and  slow.  There  is  data  duplication  in  different  product  geometries.  It  takes  nine  months  for  one 
iteration,  which  is  too  long. 

One  solution  is  to  integrate  applications,  and  to  extend  the  integration  to  manufacturability  and 
assemblability  issues.  If  you  have  point-to-point  interfaces,  if  you  add  one  application,  you  add  n- 
1 interfaces.  Thus  n nodes  have  n(n-l)/2  interfaces.  This  approach  is  expensive  and  brittle,  and 
our  company  (and  other  companies)  are  trying  to  avoid  it. 

In  contrast  to  application  integration,  our  approach  is  data  sharing  in  order  to  avoid  point-to- 
point  interfaces.  Another  reason  to  use  shared  data  is  to  decouple  our  work  from  specific  vendor 
solutions.  The  old  way  locks  us  into  specific  vendors,  which  can  be  anything  from  very  expensive 
to  catastrophic.  When  our  CAD  vendor  went  from  version  3 to  version  4,  it  took  us  500,000  per- 
son-hours to  modify  the  support  software,  and  it  still  didn’t  do  everything  we  wanted.  The  key  to 
data  sharing  is  standards.  Dr.  Harter  voiced  support  for  STEP. 

Boeing  is  involved  in  the  DARPA  MADE  program,  but  their  focus  is  slightly  different  from 
Dr.  Zarda’s.  Boeing  works  on  integration  of  design  and  analysis  programs  through  sharing  and 
standardization  of  data.  The  IPDE  (Integrated  Product  Data  Environment)  is  a subset  of  MADE. 
MADE  involves  the  improvement  of  any  kind  of  evaluation  of  design  alternatives.  We  think  our 
IPDE  vision  is  indeed  a vision,  and  not  a hallucination.  We  may  not  achieve  all  of  the  vision,  but 
we  hope  to  achieve  at  least  some  of  it. 

We  need  to  separate  applications  from  data.  The  high-level  view:  we  need  an  integrated  prod- 
uct database  based  on  standards.  We  need  reading  and  writing  via  an  SDM  (Shared  Data  Man- 
ager). We  need  a DAI  (Data  Access  Interface)  for  each  domain,  not  for  each  product.  For  exam- 
ple, we  need  a DAI  for  geometry,  and  another  for  static  stress  analysis.  Our  CAD/CAE  application 
produces  a Part  21  file  which  is  parsed  by  the  DAI.  The  DAI  takes  only  the  relevant  parts  and 
breaks  them  up  into  Units  of  Functionality  (UoFs),  such  as  wireframe  and  topology.  Units  of 
Functionality  is  a concept  borrowed  from  STEP.  The  SDM  parses  the  UoFs  into  database  entities, 
used  by  the  beta  version  of  Oracle  8.  The  entire  process  must  be  reversible. 

We  have  very  little  money,  so  we  are  working  with  a small  set  of  applications.  For  CAD  we 
are  taking  CATIA.  For  aerodynamic  flow  analysis,  we  are  using  the  Boeing  A500  code.  Our 
stress  analysis  application  comes  from  MSC  (the  MacNeal-Schwendler  Corporation).  Our  feature 
recognition  system  comes  from  Arizona  Statue  University.  We  must  ultimately  resolve  the  rela- 
tionships between  UoF  models.  Some  of  this  can  be  done  by  the  DAI  if  two  UoFs  are  within  the 
application  domain.  Some  must  be  done  by  the  SDM  if  one  UoF  is  outside  the  application  domain. 

Prototype  1A  of  IPDE  will  be  completed  on  schedule  at  the  end  of  this  month.  It  is  a minimal 
version  of  a multidisciplinary  optimization.  Prototype  IB  is  the  initial  version  of  the  SDM,  in- 
cluding an  interface  for  static  stress  analysis.  The  December  1996  deadline  is  sliding,  because  the 
Oracle  version  8 software  was  eight  weeks  late.  The  release  of  IPDE  version  1 is  set  for  June 
1997.  CAD,  Computational  Fluid  Dynamics  (CFD),  and  Finite  Element  Analysis  (FEA)  should  be 
in  place,  with  SDM  and  a shared  database.  The  demonstration  article  is  a section  of  the  wing  of  the 
V22.  The  problem  with  some  applications  was  the  sensitivity  of  data  and  information.  We  wanted 
to  use  an  AW  ACS  (Airborne  Warning  And  Control  System)  example,  which  the  military  ap- 
proved, but  the  commercial  part  of  Boeing  did  not. 
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Design  Data  Treatment  Issues  at  Boeing  Helicopters 

Dr.  Gary  Coen,  Boeing  (gary.a.coen@boeing.com) 

(5  slides  start  after  page  183) 


Dr.  Coen  introduced  himself  as  working  for  Boeing  Helicopters  in  Philadelphia,  which  builds 
the  V-22,  Comanche,  and  Chinook. 

Most  of  the  design  work  at  Boeing  Philadelphia  involves  use  of  a database  tool  called  EPIC, 
and  CATIA  datasets.  This  system  indexes  and  retrieves  data  by  aircraft  model  number  plus  a 
drawing  tree  representation  of  aircraft  subsystems.  For  each  dataset,  the  index  is  formulated  as  a 
composite  key.  For  instance,  the  index  901-X-0001  identifies  the  V-22  aircraft  model  with  the 
901-  prefix,  X identifies  a configured  subsystem  (e.g.,  avionics,  structures,  propulsion,  etc.),  and 
the  0001  picks  out  a section,  assembly,  or  detail  part  of  that  subsystem.  The  idea  is  to  view  the 
index  scheme  as  incorporating  a limited  notion  of  metadata.  This  indexing  scheme  has  been  suffi- 
cient to  produce  helicopters.  It  has  no  information  about  requirements,  constraints,  costs,  or  a 
mapping  between  requirements  and  constraints.  If  any  of  this  information  were  there,  it  would 
certainly  be  used. 

An  indexing  scheme  has  to  be  useful.  Users  tell  us  that  it  would  be  useful  if  the  repository  of 
designs  had  a good  indexing  scheme  useable  by  each  suborganization. 

hi  the  past,  various  attempts  at  process  re-engineering,  such  as  Group  Technology,  were  initi- 
ated, but  each  had  its  shortcomings.  Group  Technology  was  about  the  “piggybacking”  of  auxiliary 
information  on  the  indexing  schemes,  for  example  the  tables  on  the  “Feature-Based  Design  Storage 
and  Retrieval”  slide.  This  idea  was  very  well-received  and  there  was  a lot  of  requirements- 
gathering.  But  the  system  was  not  ideal  for  users  who  had  to  respond  based  on  the  back-end  fea- 
tures of  an  expert  system,  which  therefore  had  to  be  error-free;  this  was  impossible.  Thus  it  was 
ultimately  rejected  and  is  now  a historical  article.  It  did  not  capture  design  intent. 

If  a new  system  were  to  be  developed  and  integrated  with  a PDM,  it  would  be  useful  for  ca- 
pacity planning  by  process  planners  and  industrial  engineers.  We  do  not  have  a dedicated  factory 
floor,  but  rather  a competitive  dynamic  schedule. 

Feature-based  information  would  be  very  helpful  for  designers.  A supplement  to  the 
CATIA/EPIC  system  is  the  feature-based  ProEngineer  design  tool  combined  with  IGES  data 
translation.  We  are  focusing  on  these  systems  to  provide  output  for  MADE.  In  our  use  of  ProEn- 
gineer, we  still  use  the  assembly  drawing  number  as  the  primary  index.  A design  feature  index 
would  have  a high  return  for  the  company.  A standard  catalog  of  parts  would  be  useful  to  engi- 
neers. A feature  library,  though  constructed  over  time,  would  pay  for  itself  through  re-use. 

Engineers  want  real-time  construction  of  lessons  learned — design  instances  that  satisfy  con- 
straints and  requirements.  One  candidate  for  an  indexing  scheme  would  be  a feature-centric  in- 
dexing scheme,  referring  to  design  elements  and  constraints  that  were  believed  to  be  satisfied. 

The  ultimate  rationale  for  design  repository  schemata  is  to  encode,  for  each  design,  useful 
metadata  to  support  retrieval  and  reuse.  But  even  this  will  not  be  sufficient  to  guarantee  capture  of 
intangibles  like  intent  and  rationale.  Kevin  Lyons  relates  a story  about  how  Lee  Iacocca  imposed  a 
three-inch  length  reduction  on  a Mustang  in  order  to  affect  a nine-inch  reduction  in  space  require- 
ments for  three  Mustangs,  in  order  to  fit  three  (not  two)  Mustangs  on  a single  rail  car  for  transport 
to  market.  The  underlying  rationale  for  this  cost-driven  reduction  in  length  cannot,  in  general,  be 
associated  with  the  drawings  which  implement  it.  However,  a PDM  could  be  useful  in  coordinat- 
ing the  distribution  and  use  of  such  information. 

To  summarize  my  perception  of  what  Boeing  requires,  design  engineers  and  others  in  the  en- 
terprise need  access  to  information  about  the  entire  aircraft,  and  this  can  only  be  implemented  by 
capturing  the  relevant  feature  geometry,  thus  supporting  clustering  of  designs  which,  in  turn,  will 
support  reuse.  We  must  capture  design  rationale,  which  currently  remains  unidentified,  and  we 
must  capture  design  intent,  perhaps  deriving  it  from  construction  history,  by  analyzing  design 
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change  trends  made  evident  in  its  revision  history.  Most  importantly,  we  need  to  integrate  the  de- 
sign data,  lessons-leamed  documentation,  and  product  data  management  technology. 

A question-and-answer  period  followed  Dr.  Coen’s  talk.  Questioners  are  identified  by  num- 
ber. 


Ql:  Do  you  have  plans  to  incorporate  process  yield,  reject  history,  or  cost  data?  It  doesn’t 
show  the  effect  of  design  decisions. 

A:  Group  Technology  did  that,  and  it  was  useless.  The  defense  industry  players  implemented 
a shallow  standard  rejection  process.  That  information  is  valuable  for  the  design  repository,  but  it 
really  is — or  should  be — part  of  the  requirements. 

Q2:  Have  you  tried  using  conventional  object-oriented  techniques? 

A:  Our  techniques  have  been  very  ad-hoc  to  this  point.  We’re  trying  to  make  them  less  so. 


Seven  Proposed  Applications  of  Product  Data  Management 

Wayne  Collier,  D.  H.  Brown  & Associates  (wayne@dhbrown.com) 

(slides  unavailable) 


Dr.  Sriram  introduced  Mr.  Collier  as  an  expert  in  product  data  management  (PDM).  Mr.  Col- 
lier said  that  he  would  do  comparisons  between  product  data  management  systems. 

Mr.  Collier  described  Arthur  C.  Clarke’s  short  story,  “Superiority”.  In  the  story,  a military 
officer  testifies  in  front  of  a tribunal  that  his  side  had  lost  because  its  enemy  had  had  far  inferior 
technology.  They  won  the  first  battle,  having  more  and  better  technology  than  their  foes.  But  they 
didn’t  win  as  strongly  as  they  had  hoped,  and  they  realized  the  war  would  take  too  long.  The 
technology  research  group  said  “We  haven’t  updated  our  technology  for  one  hundred  years.  We 
can’t  make  it  just  a little  bit  better.  We  need  to  make  it  all  better  at  once.”  In  an  attempt  to  do  this, 
the  results  was  advanced  technology  that  was  almost  right,  but  consistently  failed  because  it  was 
only  “almost”  right.  In  industry,  Mr.  Collier  works  in  areas  that  are,  similarly,  extremely  good, 
almost  right,  and  very  frustrating. 

There  was  a structure  proposed  in  Administrative  Magazine  in  1990.  The  structure  was  not 
quite  “worse  is  better”,  but  something  like  “technology  fails  in  established  firms  when  one  small 
mundane  thing  is  wrong”.  The  important  question  is:  is  new  technology  in  the  context  of  the  pre- 
vious framework?  The  idea  can  be  expressed  in  a two-by-two  grid: 


Limited  Technology  Change 

Substantial  Technology  Change 

Core  Framework 
Maintained 

Incremental  Innovation 

Modular  Innovation 

Core  Framework 
Overturned 

Architectural  Innovation 

Radical  Innovation 

A company  learns  less  well  with  modular  innovation  than  with  incremental  innovation.  A 
company  learns  less  well  with  architectural  innovation  than  with  incremental  innovation.  But  a 
company  learns  very  well  with  radical  innovation. 

A new  core  business  process  is  a move  from  maintaining  the  core  framework  to  overturning 
the  core  framework.  New  tools  are  a move  from  a limited  technology  change  to  a substantial  tech- 
nology change.  It’s  easy  to  move  from  an  incremental  innovation  to  a modular  innovation.  It’s 
worst  to  move  from  an  incremental  innovation  to  an  architectural  innovation  or  to  a radical  innova- 
tion— yet  that’s  what  consultants  often  say  to  change. 

The  most  successful  progression  is  from  incremental  innovation,  to  modular  innovation,  to 
architectural  innovation,  and  only  then  to  radical  innovation.  Progressing  from  modular  innovation 
to  architectural  innovation  means  restricting  the  use  of  tools  and  moving  to  a new  business  proc- 
ess. We  did  this  with  word  processors  and  office  automation  products.  You  have  time  to  learn  the 
meaning  of  your  business  processes. 

If  you  ask  someone  what  a PDM  system  does,  you  get  different  answers.  An  engineer  says 
that  it’s  a design  repository.  A process  control  manager  says  that  it’s  a change  and  configuration 
management  system,  or  a parts  classification  management  system,  or  a product  management  sys- 
tem. A manufacturer  says  that  it’s  a build-on-demand  system.  A business  process  manager  says 
that  it’s  a process  workflow  system.  This  doesn’t  make  sense,  but  what  is  really  happening  is  that 
people  are  describing  what  they  need.  To  be  successful,  listen  to  the  customers:  choose  one,  be- 
come good  at  it,  and  ignore  the  rest. 

For  the  first  application,  change  management,  Agile  Software  makes  a PC-only  tool  for  do- 
main-management. For  the  second  application,  part  classification,  use  Aspect  with  commercial 
part  libraries  on  line,  or  CATIS  (Computer  Aided  Tactical  Information  System)  with  internal  part 
database  normalization.  There  are  problems  with  domain-specific  solutions.  For  the  third  applica- 
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tion,  design  repositories,  Workgroup  Technology  makes  an  up-front  STEP-free  integration  system 
that  saves  parameters,  as  parametric  systems  are  more  generally  known  and  useable.  Some  prob- 
lems would  be  easy  to  solve  if  the  right  people  would  work  on  boring  things.  For  the  fourth  appli- 
cation, we  should  build  and  configure  engineering  data  on  demand.  This  would  involve  generic 
and  generative  bills  and  materials. 

The  product  family  concept  is  important.  For  modular  structure,  define  core  components  that 
are  similar  across  many  families.  Modules  are  defined  in  terms  of  interfaces  to  core  components. 
Another  layer  might  be  provided  by  AT&T  Bell  Labs/Lucent  Technologies.  As  we  configure,  con- 
sider cost  constraints  and  variable  constraints.  This  is  how  AT&T  develops  telephone  switching 
hubs  (with  researchers  from  the  University  of  Eindhoven).  An  IBM  product  manager  is  ahead  of 
Metaphase.  There  is  nothing  like  serial  change  management. 

For  the  fifth  application,  we  need  a collaborative  workgroup  enabler.  This  is  what  the  original 
assembly  tools  were  built  for.  What  is  the  day-to-day  environment?  We  need  non-invasive  tools 
in  the  concurrent  engineering  context.  For  the  sixth  application,  we  need  imaging,  replacing  paper 
with  scanners  and  printers.  For  the  seventh  application,  we  need  global  product  life-cycle  model- 
ing, beginning  with  the  commercialization  of  a product  and  ending  with  its  obsolescence. 
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Use  of  Standards  for  Data  Storage  and  Exchange 

Gene  Allen,  The  MacNeal-Schwendler  Corporation  (gene.allen@macsch.com) 

(8  slides  start  after  page  189) 


Mr.  Allen  described  himself  as  having  worked  with  industry  and  government  for  ten  years  in 
collaborative  research  and  development  programs. 

Ours  must  be  a rapid-response  program,  reducing  the  response  time  in  design.  Collaborative 
development  is  the  vision  for  most  people.  We  have  common  requirements  to  achieve  to  arrive  at 
that  vision:  we  must  have  an  accurate  model  of  reality,  with  interoperability,  that  is  easy  to  use. 

CAD,  CAM  (Computer-Aided  Manufacturing),  and  CAE  evolved  from  different  parts  of  the 
industry.  They  were  not  originally  intended  to  be  integrated. 

The  Rapid-Response  Manufacturing  (RRM)  program  has  as  its  objective  a heterogeneous  ar- 
chitecture. It  was  adopted  by  NIIIP  (National  Industrial  Information  Infrastructure  Protocols). 
EXPRESS  captures  information.  The  “Architecture  for  Interoperability”  slide  is  a high-level  over- 
view of  the  model:  much  work  needs  to  be  done,  and  different  pieces  are  at  MSC  (the  MacNeal- 
Schwendler  Corporation).  Ed  Stanton’s  generic  pre-  and  post-processor  can  analyze  anybody’s 
CAD/CAM  output.  The  company  adopted  EXPRESS  internally. 

MSC  is  working  on  interfaces  to  PDM  systems  through  CORBA  (Common  Object  Request 
Broker  Architecture)  wrappers.  These  interfaces  are  ease-of-use  issues.  Industry  drivers  are  a 
product-specific  focus. 

Materials  are  as  variable  as  geometry.  MVISION  provides  materials  information  in  a com- 
puter-readable form.  End  users  perform  analysis  as  part  of  the  design  process.  The  MVISION 
database  architecture  supports  interoperability,  reusability,  and  object-orientation.  It  is  modeled  in 
EXPRESS  and  compliant  with  STEP  Part  45,  and  can  be  tied  in  with  any  PDM  system. 
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Integrating  a Distributed , Agile , Virtual  Enterprise  in  the  TEAM 

Program 

Kim  Cobb,  Lockheed  Martin  (cli@ornl.gov) 

(24  slides  start  after  page  198) 


Mr.  Cobb  began  by  describing  the  mission  of  the  TEAM  (Technologies  Enabling  Agile  Manu- 
facturing) program.  Agility  is  the  ability  to  respond  quickly  to  unanticipated  changes.  The  TEAM 
program  includes  GM,  Ford,  and  Pratt  & Whitney,  and  NIST  in  three  of  five  project  areas.  TEAM 
focuses  on  implementation,  not  development.  The  idea  is  to  find  tools,  put  diem  in  a toolkit,  and 
demonstrate  the  toolkit  through  product  vehicles.  The  TEAM  goals  are:  better,  faster,  cheaper. 
TEAM  hopes  to  provide  a plug-and-play  environment. 

The  “Team  Product  Realization  Model”  slide  shows  three  phases  of  customer  requirements. 
Concept  optimization  involves  design/manufacturing  tradeoffs  during  the  performance  evaluation 
phase.  Virtual  manufacturing  involves  the  simulation  and  analysis  of  products  and  resources. 

In  March  1996,  TEAM  demonstrated  a part  of  interest  to  the  aerospace,  automotive,  and  de- 
fense industries.  There  is  a web  repository  for  files.  The  part  was  created  at  GM  and  inspected  at 
Ford.  Enterprise  Integration  Thrust  Area  Activities  include  the  Intersite  File  Manager.  It  was  en- 
hanced for  Netscape.  An  early  issue  encountered  was  the  need  to  deal  with  firewalls — the  Intersite 
File  Manager  gave  us  an  opportunity  to  deal  with  this  real-world  problem.  The  manager  uses  ex- 
isting hardware  and  software,  and  it  has  user  authentication  to  provide  access  control.  It  puts  users 
into  groups;  if  a file  in  a given  group  is  updated,  all  group  members  are  notified.  The  Intersite  File 
Manager  screen  capture  slide  shows  what  has  been  done  up  to  this  point.  One  can  get  to  a file 
simply  by  clicking  on  it. 

Next  summer,  TEAM  moves  to  seamless  deployment,  providing  infrastructure  for  various 
tools.  The  concept  of  a cockpit  is  important:  one  web-based  front-end  to  several  tools.  The  Web 
Integration  Manager  knows  what  needs  to  be  performed  and  invokes  the  appropriate  tools.  It  noti- 
fies the  next  person  in  line,  and  provides  files  to  that  person. 

Clicking  on  “optimization”  in  the  Web  Integration  Manager  results  in  a detailed  model.  The 
Web  Integration  Manager  knows  what  inputs  are  expected,  what  outputs  will  be  created,  and  what 
resources  need  to  be  invoked.  Consider  automation  of  concept  optimization.  We  can  change  the 
values  of  ProEngineer  parameters  and  run  the  optimization  engine  until  the  conceptual  design  is 
optimized.  One  conceptual  designer  can  do  CAD  analysis,  thermal  analysis,  stress  analysis,  and 
cost  analysis. 

Using  the  Concept  Optimization  Cockpit,  we  can  update  the  ProEngineer  model  without  being 
on  the  ProEngineer  workstation.  For  example,  we  can  change  the  diameter  of  a cylinder  bore  and 
have  the  ProEngineer  model  automatically  be  updated.  We  can  click  on  buttons  to  perform  analy- 
sis or  optimization.  We  can  do  this  for  a detailed  design  as  well  as  a conceptual  design;  the  “Con- 
cept Optimization  Cockpit”  slide  just  shows  a proof-of-concept — fine  meshes  lead  to  a slow  dem- 
onstration, coarse  meshes  lead  to  a fast  and  therefore  a better  demonstration. 

For  additional  information,  you  can  take  a look  at  our  web  pages  at 
<http  ://ce  w w w .eng.  oml . go  v/team/home.  html>. 

A question-and-answer  period  followed  Mr.  Cobb’s  talk.  Questioners  are  identified  by  number. 

Ql:  How  good  are  the  object-oriented  design  facilities? 

A:  Not  as  good  as  we  had  hoped. 

Ql:  How  do  you  handle  Phase  0,  Phase  1,  and  Phase  2 management  processes? 

A:  I glossed  over  that  in  the  talk.  The  Intersite  File  Manager  provides  version  control;  scripts 
have  files  that  “scripting”  doesn’t  change,  even  if  we  update  the  version. 

Ql:  Who’s  commercializing  TEAM? 

A:  Ask  me  off-line. 
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Engineering  Repository  Projects  at  NIST 

Dr.  Simon  Szykman,  NIST  (szykman@cme.nist.gov) 
(18  slides  start  after  page  223) 


Dr.  Szykman  discussed  engineering  repository  projects  at  NIST.  He  focused  on  small-scale 
projects.  Dr.  Szykman  gave  an  overview  of  his  talk:  he  would  discuss  motivations  for  the  work, 
then  two  existing  case  studies,  then  future  work. 

The  motivation  is  to  bring  information  together  into  a single  repository,  or  into  a distributed 
information  repository  that  may  contain  many  different  kinds  of  information.  Currently,  ideas  are 
broad  and  the  long-term  objectives  require  better  definition. 

The  first  project,  the  Design  Repository  Project,  is  a subset  of  what’s  on  the  “Design  Reposi- 
tory Project”  slide.  The  last  three  ovals  are  commercial,  off-the-shelf  databases.  At  the  top  are 
interfaces,  either  existing  or  to-be-developed.  Our  focus  is  what’s  in  the  middle.  The  idea  of  the 
Design  Repository  Project  is  not  to  let  the  representation  constrain  the  way  that  people  create  the 
design,  and  to  provide  a human-interpretable  representation  for  engineering  artifact  information. 

The  Design  Repository  Project  uses  STEP  AP  203  (Configuration  Controlled  Design)  as  one 
aspect  of  the  representation.  STEP  is  limited  primarily  to  geometry;  thus  additional  representations 
for  other  types  of  information  used  by  designers  are  required. 

For  example,  consider  a power  drill.  The  attribute  buttons  shown  in  the  slides  bring  up  addi- 
tional windows.  Click  on  a drill  subsystem,  drill_system_l,  then  click  on  motor_function_l. 
Keep  clicking  for  additional  information.  The  aggregate  idea  represented  is  that  the  function  of  the 
motor  is  to  transform  electrical  current  coming  in  from  the  black  wire,  into  rotational  motion  at  the 
clutch  base.  A STEP-based  viewer  allows  visualization  of  the  artifact  geometry. 

The  second  case  study,  the  NIST  Design,  Planning,  Assembly  Repository,  contains  parts  and 
assemblies  in  different  formats.  These  formats  include  ProE,  IGES,  and  PostScript.  The  reposi- 
tory also  contains  some  process  plans.  The  goals  of  the  repository  are  to  identify  benchmark  cases 
and  problems,  and  to  make  them  publicly  available  over  the  World  Wide  Web.  These  are  real 
models,  not  toy  models,  many  of  which  were  provided  by  industry  contributors. 

Areas  for  future  research  include  coming  up  with  indexing  schemes  for  information.  We  need 
a better  definition  of  data  first.  Limitations  inherent  in  STEP,  such  as  lack  of  representations  for 
features  and  constraints,  must  also  be  addressed. 

A question-and-answer  period  followed  Dr.  Szykman’ s talk.  Questioners  are  identified  by 
number. 

Ql:  What  do  I do  with  a process  plan? 

A:  You’ll  have  to  talk  to  Dr.  Bill  Regli  (wregli@mcs.drexel.edu),  who  maintains  the  parts  re- 
pository. Some  plans  are  numerically  controlled  (NC)  machine  process  plans;  some  are  more  so- 
phisticated. 

Q2:  We  could  at  least  see  what  processes  were  being  used. 

A:  One  idea:  have  a part,  find  a similar  part,  or  retrieve  a process  plan.  This  allows  case-based 
planning,  or  variant  process  planning. 

Ql:  Do  you  sort  the  repository  by  similarities? 

A:  There  is  no  sorting  mechanism  in  the  repository.  You  can  search  on  attributes  of  the  part 
models,  such  as  keywords  in  file  names,  CAD  file  types,  and  so  on. 

Ql:  Do  you  have  any  generic  thoughts  on  design  repositories — what  should  be  in  them,  how 
to  access  them? 

A:  Those  are  among  the  reasons  we  organized  this  workshop;  I could  give  my  thoughts  but  I’d 
rather  not  impose  my  biases  on  the  audience.  At  the  very  least,  web-based  access  is  a good  idea. 
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Open  Collaborative  Engineering 

Dr.  Michael  Case,  Concurrent  Engineering  Research  Laboratory 

(m-case@cecer.army.mil) 

(14  slides  start  after  page  242) 


Dr.  Case’s  problem  domain  is  facilities  and  buildings.  There’s  no  machining  and  they  don’t 
fly,  but  otherwise  the  problem  domain  has  similar  variables  to  those  discussed  by  the  previous 
speakers,  and  a variety  of  issues  associated  with  design  repositories. 

The  Army  Corps  of  Engineers  is  the  largest  construction  “company”  in  the  world.  But  square 
footage  of  new  construction  is  shrinking  daily  and  funds  are  shrinking  even  more  quickly.  People 
now  care  about  entire  life  cycles,  not  just  the  design  stage.  People  who  design  buildings  never 
meet  people  who  live  there.  Buildings  remain  for  ten,  twenty,  or  fifty  years;  information  for  old 
buildings  may  be  stored  in  old  formats  on  eight-inch  disks.  There  are  thus  archival  problems. 

The  Architect’s  Associate  is  software  designed  to  help  architects  work.  It  is  an  object-oriented 
design  repository  with  links  into  a CAD  system.  It  is  shown  on  the  slide  in  AutoCAD,  though  it 
could  be  MicroStation.  Conflict  resolution  is  done  with  a distributed  design,  not  client-server. 

Consider  the  “Discourse  Model”  slide.  On  that  slide,  ontology  is  equivalent  to  library;  the 
messaging  systems  are  event-based;  there  is  management  of  permissions  and  ownership  of  arti- 
facts. The  implementation  is  in  a homogeneous  environment,  as  is  the  CAD  system,  which  is  un- 
desirable. 

The  Agent  Collaboration  Language  project  involves  building  a design  on  the  Internet.  Stanford 
worked  on  the  facilitator  model,  Massachusetts  Institute  of  Technology  worked  on  the  structural 
engineering,  Carnegie  Mellon  University  worked  on  another  system,  and  so  forth.  An  interesting 
note:  the  project  abandoned  the  idea  of  a common  representation  and  embraced  point-to-point 
translation  which  comes  back  to  the  n2  translators  problem — but  n is  small  in  this  case.  The  trans- 
lation engine  could  easily  become  “bogged  down”;  it  was  on  a single  machine,  which  was  slow 
when  it  was  busy,  thus  it  has  now  been  distributed. 

The  CITYSCAPE  architecture  is  used  for  installation  and  management.  The  idea  is  to  break 
things  up  into  several  services,  such  as  CAD,  Geographic  Information  Systems,  and  so  on.  The 
goal  is  to  manage  workflow  and  work  orders.  The  architecture  takes  front-end  engineering  model 
designs,  and  has  them  flow  through  to  those  who  need  them.  They  are  spending  millions  and  mil- 
lions of  dollars  to  put  maps  and  other  hard-copy  information  back  into  the  system. 

The  Modular  Design  System  arose  because  the  Army  Reserve,  like  the  post  office,  wanted 
standardization  of  building  components.  The  technology  they  were  using  was  dated,  and  they 
wanted  to  update  it.  The  Modular  Design  System  allows  the  user  to  drag  and  drop  pre-configured 
reusable  components.  Design  time  was  cut  from  eighteen  months  to  six  months.  The  system  pro- 
duces 80%  of  construction  documents.  Its  limitation  is  that  it  focuses  on  Army  Reserve  Centers;  it 
is  difficult  to  add  new  types  of  buildings. 

In  the  next  four  years,  the  intention  is  to  introduce  new  technologies  (from  the  top  of  the  Open 
CE  CRaDA  slide)  to  produce  new  products  (at  the  bottom  of  the  slide).  Right  now,  resource  files 
are  hard  to  maintain.  First,  we  need  something  maintainable,  at  least.  Next,  we  need  to  move  to 
an  object-oriented  database.  Also,  we  need  to  allow  multiple  people  to  work  together.  We  have  a 
laundry  list  of  research  and  development  issues.  The  sole  reason  for  plug-and-play  is  that  we 
don’t  want  to  be  locked  into  specific  vendor  solutions.  We  want  to  reason  about  relationships 
between  objects,  so  we  need  a separate  relationship  repository.  We  hope  to  be  able  to  browse  on 
the  web,  find  a heat  exchanger,  and  drop  it  into  a design;  we  need  an  enabling  language  to  do  this. 

Suppose  in  1996,  we  create  a drawing,  and  keep  it  around  for  fifty  years,  and  the  specifica- 
tions change?  There  is  a schema  evolution  problem.  Versioning  for  designs  has  been  derived 
from  software  engineering  versioning.  But  we  need  a better  versioning  system.  Chronology  in- 
volves how  things  change  over  time.  Ownership  is  important  metadata:  who  created  a particular 
design? 
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We  need  software  agents  to  manipulate  models.  We  need  visualization;  no  application  comes 
without  its  own  custom  user  interface.  We  need  visualization  engines;  VRML  (Virtual  Reality 
Modeling  Language)  is  evolving  into  one.  We  are  interested  in  replication,  as  different  parts  of 
models  may  show  up  in  different  places. 

Dr.  Collier  interrupted  Dr.  Case  to  ask  if  they  used  pre-existing  commercial  tools.  Dr.  Case 
replied  that  they  were  using  only  relational  databases,  not  translation.  Dr.  Collier  commented  that 
toolkits  for  passing  around  design  tools  exist,  but  are  criticized  because  they  are  not  used  in  real 
applications.  Because  Dr.  Case  was  creating  a real  application,  Dr.  Collier  urged  him  to  use  these 
toolkits.  Dr.  Collier  continued  by  saying  that  we  will  always  need  translation.  University  of 
Southern  California,  Stanford  University,  and  IBM  came  up  with  win-win  strategies  for  conflict 
management. 
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Integrated  Design  Systems : Aeronautics  Design  Process  Improvement 


Dr.  David  E.  Thompson,  NASA  Ames  Research  Center, 
Computational  Sciences  Division  (dethompson@mail.arc.nasa.gov) 
(20  slides  start  after  page  257) 


Dr.  Thompson  began  by  mentioning  that  NASA  has  shifted  its  focus  from  basic  research  and 
development  to  providing  more  support  for  the  economic  competitiveness  of  the  United  States. 
One  possible  focus  for  this  support  is  Integrated  Design  Systems.  As  part  of  that  focus.  Dr. 
Thompson  works  on  Aeronautic  Design  Process  Improvement.  The  first  goal  in  this  work  is  to 
assess  what  the  aeronautics  industry  needs  NASA  Ames  to  work  on.  The  Airbus  plane  is  a heavy, 
modular  aircraft,  and  is  generally  cheaper  to  build  than  typical  U.S.  commercial  aircraft.  And  be- 
cause of  its  relatively  lower  price,  the  U.S.  aerospace  industry  needs  to  reduce  cost  by  about  25% 
to  compete  with  Airbus  pricing.  The  cost  driver  provides  a variety  of  opportunities  for  improve- 
ment. NASA  is  not  involved  in  commercial  business  practices,  cost  models,  or  profit  strategies; 
those  are  industry’s  job.  But  NASA  can  work  at  improving  the  overall  design  process  with  the 
infusion  of  advanced  information  technology  tools  and  systems. 

Much  of  a commercial  aircraft  designer’s  work  is  derivative,  involving  redesign.  NASA  fo- 
cuses not  just  on  the  conceptual  stage,  but  across  the  whole  development  lifecycle.  Dr.  Thomp- 
son’s program  strategy  consists  of  providing  a testbed  to  co-develop  technology  with  industry  so 
that  the  overall  lifecycle  can  take  advantage  of  emerging  technology. 

Dr.  Thompson  defined  a “thread”  to  be  a design  activity  involving  one  or  more  engineering 
disciplines.  One  design  process  improvement  target  is  reducing  time  duration  for  a single  thread. 
For  example,  consider  wind  tunnel  usage.  Currently,  validation  and  analysis  of  wind  tunnel  mod- 
els is  an  iterative  process,  lasting  about  24  months,  consisting  of  3 eight-month  cycles.  Fre- 
quently, by  the  time  the  wind  tunnel  testing  of  a model  is  complete,  the  designers  have  changed  the 
design.  To  make  the  design  process  quicker,  one  can  improve  the  use  of  wind  tunnels  by  provid- 
ing on-line  remote  access  to  the  experimental  data  as  well  as  to  similar  computational  fluid  dynam- 
ics results.  This  eliminates  some  of  the  analysis  and  redesign  needed,  decreasing  the  time  for  each 
iteration  and  increasing  overall  effectiveness  of  time  spent  at  the  tunnels. 

Another  design  process  target  is  the  speeding  up  and  unification  of  multiple  threads.  In  the 
1990’s,  after  the  requirements  are  given,  designers  independently  work  on  an  aerodynamics 
thread,  a structures  thread,  a stability  and  controls  thread,  and  so  forth.  After  some  time,  configu- 
ration management  occurs,  and  the  designs  are  reconciled,  making  a moderate  design  improvement 
at  the  cost  of  a significant  amount  of  time.  In  the  decade  of  the  2000’ s,  advanced  software  systems 
that  support  configuration  management  and  control  of  the  product  model  can  control  more  frequent 
updates,  resulting  in  a high  frequency  of  small  design  improvements.  Because  the  design  is  under 
a deadline,  these  higher  frequency  changes  will  allow  faster  response  to  changing  requirements, 
exploration  of  a greater  number  of  alternatives,  and  will  produce  a better  product. 

Consider  a design  activity  example  using  the  type  of  interactive  system  envisioned.  Suppose 
you’re  a designer,  and  your  job  on  a given  day  is  to  select  a radar  for  a plane  under  design.  First, 
you  acquire  and  display  the  data  and  constraints  for  radars  available  from  vendors.  Understanding 
how  stiff  or  restrictive  the  design  constraint-space  is  helps  determine  what  vendors  could  provide 
an  acceptable  radar  that  fits  in  the  plane  nose-cone.  A non-interactive  design  system  might  lead 
you  to  think  that  there  is  only  one  acceptable  radar. 

But  what  about  understanding  the  nature  of  the  constraints?  Say  there  is  a nose-cone  volume 
constraint  which,  if  relaxed,  would  allow  another  acceptable  radar  at  a significant  savings  in  cost. 
You  might  try  increasing  the  size  of  the  dome  in  the  nose  of  the  aircraft  to  provide  the  additional 
volume.  Then,  the  design  system  would  allow  you  to  start  up  a collaborative  activity,  consulting 
with  experts  in  manufacturing  and  operations,  structures,  and  aerodynamics,  to  evaluate  the  new 
design  configuration.  The  experts  in  structures  and  manufacturing  might  approve  the  change  based 
on  acceptable  materials  and  size,  and  the  aero  expert  might  launch  a CFD  code  that  indicates  that 
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the  larger  dome  is  still  small  enough  that  no  new  turbulence  would  be  induced.  The  change  would 
then  be  approved,  the  product  model  updated,  and  the  less  costly  radar  system  ordered. 

A workshop  participant  interrupted  Dr.  Thompson  to  ask  if  he  had  such  a system.  Dr.  Thomp- 
son replied  that  NASA  is  building  a first  prototype  of  such  a system  this  year  [1996-97]. 

Dr.  Thompson  said  that  NASA  has  invested  in  intelligent  database  and  knowledge  extraction 
techniques,  intelligent  tools  and  modeling  representations,  smart  systems  integration  agents  and 
data  fusion.  NASA  is  now  investing  in  collaborative  communication  tools  and  infrastructure,  im- 
mersive environments  and  navigation  capabilities,  and  a distributed,  high  performance  simulation 
design  environment.  The  collection  of  these  capabilities  will  provide  the  backbone  of  the  future 
improvements  envisioned. 

Dr.  Thompson’s  program  plan  involves  developing  only  what  can’t  be  acquired  commercially. 
The  technology  transfer  plan  is  unique  because  the  technology  is  being  co-developed  so  that  trans- 
fer evolves  as  development  evolves.  Roughly  80%  of  the  effort  is  being  done  collaboratively. 

A question-and-answer  period  followed  Dr.  Thompson’s  talk.  Questioners  are  identified  by 
number. 

Ql:  Who  are  your  partners  from  the  commercial  information  technology  environment? 

A:  We  are  still  sorting  them  out.  Ames  was  awarded  more  than  anticipated  for  this  prototype  sys- 
tem, and  we  are  in  the  process  of  putting  together  a work  plan  and  spending  plan. 

Q2:  Some  companies  say  they  focus  on  collaborative  design  display— would  you  spend  money  on 
them? 

A:  That’s  too  narrow  at  this  point.  Suppose  the  problem  is:  what  is  the  amount  of  lift  during 
landing?  The  design  problem  is:  what  is  the  best  proportion  of  overlap  versus  gap  for  the  wing 
flap  to  maximize  the  lift?  Using  a new  visualization  tool,  a designer  might  get  contours,  showing  a 
variety  of  configurations  that  give  maximum  lift.  But  given  deployment  constraints,  then  the  best 
configuration  must  satisfy  those  constraints,  which  can  be  plotted  against  the  results  from  simple 
computational  fluid  dynamics  runs.  Such  a design  activity  requires  completely  new  types  of  visu- 
alization capabilities  that  are  not  yet  commercially  available. 
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Model-Based  Support  for  Collaborative  Engineering— Focus  on 
Ontologies:  How  Things  Work  Project 

Dr.  Yumi  Iwasaki,  Stanford  University  (iwasaki@ksl.stanford.edu) 

(6  slides  start  after  page  278 
A paper  on  this  topic  begins  after  page  375) 


Dr.  Iwasaki  said  that  her  focus  was  on  declarative  ontologies  for  collaborative  and  multidisci- 
plinary designs,  and  on  ontology  libraries.  Her  work  is  part  of  DARPA’s  MADE  program,  and 
also  supported  by  other  DARPA  programs.  Dr.  Iwasaki  has  been  working  for  the  last  several 
years  on  model-based  reasoning  technologies,  and  automatic  modeling  formulation  for  quantity 
and  quality.  The  project  is  in  year  one  of  three,  a new  phase  in  which  she  will  deploy  and  extend 
technology  in  support  of  collaborative  engineering.  In  this  talk,  she  would  be  concentrating  on  the 
ontology  aspects  of  her  work. 

An  ontology  is  defined  as  a body  of  terminology  used  to  describe  a particular  domain  of  dis- 
course, including  classes  and  relations.  Ontologies  are  similar  to  frame-base  systems  and  define 
your  vocabulary  for  each  domain.  The  problem  in  supporting  many  disciplines  is  that  each  defini- 
tion has  its  own  ontology.  For  example,  a database,  a company,  and  a program  might  have 
slightly  different  ontologies. 

Suppose  there  is  a multidisciplinary  team  working  on  some  device.  For  example,  an  electrical 
team,  a mechanical  team,  an  optical  team,  and  a thermal  team  might  all  be  working  on  the  same 
design.  All  teams  have  different  ontologies:  across  teams,  the  same  word  might  have  slightly  dif- 
ferent meanings,  and  the  same  meaning  might  be  described  with  different  words. 

We  have  developed  a declarative  representation  of  ontology  with  definitions.  We  have  created 
a web-based  ontology  editor  that  is  available  to  the  public.  Having  the  ontology  of  one  domain  is 
very  useful;  it  shows  a conceptualization  of  the  world.  An  ontology  shows  a classification  of  ob- 
jects that  you  have.  Ontologies  are  even  more  important  in  collaborative  work. 

The  space  of  ontology  looks  something  like  the  “Domain  Specific  Ontologies”  slide.  There 
may  be  some  co-ontology  common  to  all  disciplines;  for  example,  mathematical  concepts.  But 
most  ontologies  are  not  are  broadly  applicable.  The  declared  ontology  of  disciplines  helps,  but 
domain-specific  models  are  also  necessary. 

To  allow  communication,  the  system  engineer’s  view  of  the  model  is  necessary.  For  example, 
mechanical  engineering  words  may  not  exist  in  an  electrical  engineer’s  vocabulary.  The  CDME 
(Collaborative  Design  Management  Environment)  model  can  facilitate  accurate  communication 
among  disciplines.  CDME  is  not  a universal  model;  it  is  just  sufficient  to  allow  communication. 
Our  hypothesis  is  that  it  is  not  very  productive  to  force  everyone  to  use  the  same  vocabulary. 

Our  particular  application  domain  is  a microsatellite.  This  is  a satellite  that  you  can  just  about 
put  your  arms  around.  Suppose  you  want  to  launch  and  operate  it.  We  are  modeling  the  electrical 
and  mechanical  aspects. 

Another  direction  of  our  research  is  function-based  information  retrieval.  We  were  told 
many  times  by  electrical  engineers  that  information  retrieval  is  a big  problem.  Unless  you  know 
what  you’re  looking  for,  it  is  very  difficult  to  find  a product.  Existing  catalogs  are  organized  along 
conventional  classifications.  We  are  developing  two  ontologies  of  functions:  one  large,  one  small. 
We  allow  you  to  translate  the  familiar  into  the  canonical. 
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The  Shared  Design  Manager:  A Repository  for  Integrated  Product 

Data 

Dr.  Susan  Urban,  Arizona  State  University  (s.urban@asu.edu) 

(7  slides  start  after  page  282) 


Dr.  Urban  introduced  her  talk  as  a continuation  of  Dr.  Harter’s  talk.  The  Shared  Design  Man- 
ager (SDM)  is  a repository,  based  on  STEP,  for  managing  data  sharing.  SDM  goes  beyond  file 
check-in  and  check-out,  addressing  issues  like  how  entities  within  files  are  related?  There  are  con- 
figuration management  issues  as  well:  what  are  the  relations?  what  are  the  iterative  processes? 

Units  of  Functionality  (UoFs)  are  subsets  of  STEP  AP  209  (Composite  and  Metallic  Structural 
Analysis  and  Related  Design).  The  idea  is  to  avoid  point-to-point  communication  by  using  UoFs 
as  the  main  units  of  data  transfer,  consisting  of  geometry,  finite  element  analysis  (FEA),  FEA  con- 
trols, and  CFD  results.  A tool  can  use  a Unit  of  Functionality  to  derive  additional  information,  and 
then  check  it. 

The  “Shared-Design  Manager  Architecture”  slide  is  a high-level  picture.  Applications  have  in- 
terfaces to  communicate  with  DAIs.  Either  a DAI  breaks  STEP  into  Units  of  Functionality,  or  it 
passes  the  STEP  to  the  SDM  to  break  into  Units  of  Functionality.  The  Integrated  Product  Database 
(IPDB)  is  based  on  the  beta  version  of  Oracle  8.  Querying  the  repository  is  much  simpler  with  a 
relational  database,  in  comparison  to  an  object-oriented  database.  EXPRESS  maps  better  to  a rela- 
tional database  than  to  an  object-oriented  database. 

Data  can  pass  inside  the  SDM  through  the  Version  Control  Unit  (VCU)  to  the  Data  Access  Unit 
(DAU).  Other  boxes  represent  other  functionality  to  be  added  to  SDM. 

A workshop  participant  interrupted  Dr.  Urban  to  ask  whether  event  notification  and  user  di- 
rectories were  standard  components.  Dr.  Urban  answered  yes,  they  were. 

Dr.  Urban  continued  by  describing  the  SDM  metadata.  Applications  map  down  to  Units  of 
Functionality,  which  sometimes  map  further  down.  Sometimes  EXPRESS  is  mapped  to  Oracle  8. 
The  ST-Developer,  an  application  from  STEPtools,  Inc.,  is  an  EXPRESS  compiler,  parser,  and 
generator.  The  “SDM  Data  Access  Unit”  slide  illustration  shows  that  a Part  21  file  comes  into  the 
system.  The  file  either  has  one  Unit  of  Functionality,  and  goes  directly  to  the  integrated  product 
database,  or  multiple  UoFs,  which  the  SDM  splits  appropriately  before  storing  in  the  integrated 
product  data  base.  The  DAI/SDM  interface  is  defined  using  CORBA,  Orbix  in  particular,  and  ex- 
tracts relationships  of  UoFs  from  Part  21  files. 
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Active  Catalogs:  A Designers  Aid 

Dr.  Peter  Will,  University  of  Southern  California  (will@isi.edu) 
(17  slides  start  after  page  290) 


Dr.  Will  said  that  his  talk  initially  consisted  of  a project  pitch,  not  as  advice.  However,  he  was 
recasting  it  into  advice.  When  he  first  began  this  project,  he  had  been  working  in  engineering 
management  for  five  years.  He  wanted  to  get  products  out  at  half  the  cost  and  with  one-tenth  the 
time  to  market.  Getting  cost  down  is  all  in  the  first  ten  percent  of  the  design,  or  maybe  even  in  the 
first  ten  minutes  of  the  design!  This  project  is  working  toward  bringing  costs  down  very  early. 

Hewlett-Packard  makes  thousands  of  products  a year,  but  not  thousands  of  new  designs  a 
year.  New  products  are  slow  because  an  error,  such  as  a bug  in  VLSI  (Very  Large-Scale  Integra- 
tion) chip  design  in  a PC  board,  requires  reworking  the  design. 

His  advice  is  to  collect  data,  then  mine  it,  then  come  up  with  a reasonable  probability  model  to 
describe  various  design  attributes.  This  should  cut  down  on  time.  Time  is  more  important  than 
money,  because  time  can  establish  a market.  Hewlett-Packard  designs  instruments  based  on  mod- 
els. If  they  expose  the  models  to  users,  they  can  design  based  on  these  exposures;  this  is  a good 
sales  tool. 

The  “Concurrent  Design  Activities”  slide  shows  the  sort  of  thing  that  should  be  in  an  active 
catalog.  Reuse  should  allow  one  to  mix  and  match  components.  We  want  to  reformulate  a partial 
functional  description  into  a set  of  reasonably  queries.  We  need  to  go  through  the  loop  on  the 
“Active  Catalogs  Scenario”  slide  lightly  and  not  deeply. 

In  general,  the  consumer  of  libraries  is  the  human  eyeball.  But  in  CAD,  geometric  models  are 
important.  We  need  to  know  the  three-dimensionality  and  the  motion  of  a part.  We  need  a search- 
able catalog  like  the  Thomas  Register.  Objects  in  active  catalogs  have  richness  and  modality.  Ac- 
tive catalog  components  are  interoperable;  usually  we  need  vector  optimization,  global  optimization 
across  domains. 

What  has  been  done?  A pump  ontology  has  been  created  that  users  can  browse  through.  A 
semantic  network  is  what  allows  the  system  to  answer  user  queries.  The  problem  is  that  it  took 
four  months  to  generate  this  ontology;  researchers  must  get  together  to  build  and  share  these  on- 
tologies! What  do  you  do  once  we  have  these  ontologies?  The  system  shown  in  the  “Active 
Catalogs  Architecture”  slide  has  been  built.  It  distributes  execution  to  the  available  resources  - 
load  balancing.  In  the  future,  it  will  run  on  the  World  Wide  Web. 
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Engineering  Design-Related  Database  Research  at  Georgia  Tech 


Dr.  Sham  Navathe,  Georgia  Institute  of  Technology  (sham@cc.gatech.edu) 

(21  slides  start  after  page  308 
A paper  on  this  topic  begins  after  page  384) 


As  the  last  talk  of  the  day,  Dr.  Navathe  stated  that  he  wanted  to  make  sure  he  started  with  a 
conclusion.  There  are  many  challenging  problems;  we  need  to  look  at  the  basic  problems  in  detail. 
We  hope  that  industry  is  receptive  to  funding  investigation  of  these  basic  problems,  not  just  to 
funding  the  delivery  of  a running  system. 

HIPED  (Heterogeneous  Intelligent  Processing  for  Engineering  Design)  was  recently  finished 
for  DARPA.  The  idea  was  to  marry  AI  (Artificial  Intelligence)  tools  to  database  back  ends.  Most 
AI  tools  are  content  with  main  memory,  and  are  not  interested  in  data  repositories.  HIPED  was 
part  of  DARPA’s  Intelligent  Integration  of  Information  (13)  program.  13  did  not  concentrate  on 
engineering  design;  rather,  it  saw  design  as  an  application  domain. 

We  map  a request  based  on  knowledge  from  the  metadata.  The  problem  in  matching  tables  is 
that  what  is  a column  name  in  one  database  is  a relation  in  another  and  a value  in  a third.  There  is  a 
heterogeneous  back-end  correspondence,  which  describes  how  relations  are  represented.  Query 
mapping  rules  take  the  query  and  process  it  for  the  back-end. 

CORAL  is  a Prolog-like  declarative  language.  It  deals  with  rule  bases  that  are  bigger  than  main 
memory.  Facts  and  rules  encode  information.  Database  correspondence  rules  describe  meta- 
knowledge processing. 

The  querying  interface  processes  certain  types  of  requests  for  demonstration  purposes.  Such 
requests  are  illustrated  in  the  slides  by  the  (Prototype  battery)  (Property  current)  query.  Consider 
two  databases.  How  can  one  map  battery  requests  to  both  databases? 

A workshop  participant  interrupted  Dr.  Navathe  to  ask  if  an  accurate  rephrasing  might  be  to 
make  consistent  queries  across  a federation  of  data  models.  Dr.  Navathe  said  yes,  plus  the  flexi- 
bility to  add  data  models  and  relationships.  A consistent  front-end  marries  data  in  the  back. 

Dr.  Navathe  continued  by  saying  that  he  was  looking  for  a partnership  with  someone  in  indus- 
try to  push  his  work  one  step  forward.  There  is  a need  to  improve  user  performance  for  large 
document,  full-text  repositories.  This  goes  along  with  visualizing  the  document  space  in  a much 
better  manner.  Schema  evolution  becomes  the  main  target  of  an  object-oriented  database  system,  a 
problem  that  we  saw  today. 

Dr.  Navathe  concluded  by  mentioning  other  big  mechanical  engineering  projects  at  Georgia 
Tech.  The  multimedia  “smart  catalog”,  meant  to  be  used  by  naive  users  through  experts,  interfaces 
databases  with  text,  videos,  and  inventory.  The  engineering  databases  in  the  School  of  Architec- 
ture are  concerned  with  research  into  view  updating. 
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Breakout  Session  # 1 — -Industry  Perspective 

Discussions  summarized  by  Dr.  Stephen  Smith  (sjsmith@nimue.hood.edu) 

(discussions  done  without  slides) 


Participants: 

• Michael  Barbieri  (chair) 

• David  Flater 

• Peter  Hart 

• Yumi  Iwasaki 

• Carl  Izurieta 

• Kevin  Lyons 

• Irena  Nagisetty 

• Linda  Schmidt 

• Stephen  Smith 

• Rich  Zarda 

In  the  discussion  that  follows,  only  Mr.  Michael  Barbieri,  the  chair,  is  identified  by  name; 
other  participants  are  not  identified. 

Q:  Let’s  brainstorm  on  topics  to  consider,  and  then  decide  which  to  present  to  the  group,  or  a 
couple  of  related  topics. 

Q:  Ideas  for  what?  Needs  for  design  repository  or  broader? 

Mr.  Barbieri:  We  could  broaden  if  you  want. 

Q:  That’s  broad  enough. 

Q:  We  want  a nationally-supported  material  database  with  as  much  meat  as  we  can  put  in  it.  It 
should  support  any  type  of  simulation,  stress  dynamics,  ordnance  analysis.  It  should  have  a good 
pedigree:  where  it  came  from.  It  should  especially  support  simulation  on  composites. 

Q:  MVTSION  is  a mechanism  to  have  that  data,  but  we  have  to  populate  it. 

Q:  We  need  standard  testing  procedures  and  results. 

Q:  We  need  chemical  properties,  physical  properties,  process  for  manufacturability  (how  mate- 
rials behave  with  processes),  thermal  coefficients,  and  electrical  properties. 

Q:  Should  we  worry  about  bottoming  out  with  specificity?  Industry  has  in-house  procedures 
for  using  data. 

Mr.  Barbieri:  NIST  puts  data  in  the  database  and  certifies  you  if  you  have  fulfilled  stan- 
dards, set  by  industry  professionals  at  NIST. 

Q:  Are  there  industry  standards  in  place? 

Mr.  Barbieri:  I don’t  think  so. 

Q:  ASTM  (American  Society  for  Testing  and  Materials)  has  standards,  but  all  tests  have  certain 
restrictions.  For  example,  how  did  the  environment  affect  the  testing,  and  associated  information 
about  how  the  testing  was  conducted. 

Q:  Even  with  ASTM  standards,  companies  perform  their  own  tests. 

Q:  There’s  so  much  research  funded  by  the  government,  but  there’s  a lot  of  overlap.  There 
should  be  a database  with  all  government  projects  in  one  place  that  you  can  search  by  keywords, 
for  example,  “high-speed  machining”.  Go  to  a web  page,  type  in  a word  search,  find  out  the  point 
of  contact,  the  purpose  , the  schedule,  the  funding  agency,  the  principle  investigator,  and  a link  to 
the  web  page  of  project.  Call  it  the  “National  Research  Database”. 

Q:  There’s  some  technical  center  in  Wheeling,  West  Virginia  called  the  Byrd  Center,  that  you 
can  search  free  of  charge,  that  includes  70%  of  the  labs  and  contacts  for  the  other  30%.  Any  gov- 
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emment-funded  activity,  when  funded,  requires  you  to  put  in  information  in  the  form  of  a one- 
page  summary. 

Q:  If  there  were  a repository,  what  information  would  be  most  useful  for  your  design  process, 
to  make  it  cost-effective  and  to  minimize  time  to  market? 

Q:  What  if  parts  and  subassemblies  were  in  a case-study  repository? 

Q:  The  Lockheed-Martin  needs:  for  500  parts  in  a gimbal,  150  of  the  500  are  off-the-shelf,  so 
we  go  to  catalogs.  We’re  trying  to  collect  these  catalogs  as  part  of  MADE/RaDEO  (Rapid  Design 
Exploration  and  Optimization).  We  need  a national  effort,  beyond  STEP.  For  bearings,  we  need 
stiffness  and  dimensions  from  graphs,  balls,  pad,  raceway,  all  on-line.  A list  of  catalogs  would 
help,  but  a standardization  of  the  format  would  really  be  useful. 

Q:  A lot  of  vendors  let  customers,  but  not  other  vendors,  have  information.  Proprietary  in- 
formation requires  security. 

Q:  Does  PartNet  let  you  search  for  bearings?  What’s  missing? 

Q:  The  details! 

Q:  What’s  PartNet? 

Q:  A research  project  that  became  a commercial  outfit,  but  it’s  very  low-scale. 

Q:  Gimbal  requirements  are  very  specific.  Bearings  are  precision-mechanical.  They  have  very 
tight  tolerances,  beyond  what  Ford  or  GM  might  need. 

Q:  Get  industry  users  together  to  set  requirements. 

Q:  But  there  are  thousands  of  user  groups! 

Q:  For  the  RaDEO  program,  say  “this  is  what  we  want.” 

Q:  If  McDonnell-Douglas  builds  gimbals,  do  they  need  that  information? 

Q:  About  70%  of  it. 

Q:  The  basic  issue  is  that  we  need  a standardized  taxonomy  of  parts  and  assemblies.  Physical 
properties  should  be  indexed  to  manufacturing  needs.  This  doesn’t  exist. 

Q:  We  need  standards  of  description  for  electronic  components,  or  any  kind  of  components. 

Q:  NIST  should  set  some  requirements  for  minimal  characterization  attributes  and  put  the  in- 
formation in  a database. 

Q:  Is  the  information  you  need  in  catalogs,  or  do  you  need  to  call  a vendor? 

Q:  It  depends.  Preliminary  decisions  and  half  of  the  final  decisions  can  be  made  with  catalogs. 
The  other  half  require  calls  to  a vendor. 

Q:  There’s  another  problem.  Suppose  that  there  is  a bearing  whose  characteristics  are  in  the 
database,  and  it  is  close  to,  but  not  quite,  what  is  wanted.  90%  of  the  time  you  can  issue  an  RFQ 
(Request  For  Quote)  and  put  in  an  order  for  something  slightly  different  than  what’s  off-the-shelf. 

Q:  A bearing  has  an  inner  radius,  an  outer  radius,  and  a hub  radius.  An  IGES/STEP  file  might 
have  more  detail,  but  you  don’t  need  it.  You  can’t,  for  motors  and  other  parts  with  more  than  three 
parameters,  search  on  the  STEP  file.  Also,  you  need  a footprint  to  perform  interference  checking. 

Q:  Perhaps  a database  with  different  levels  of  detail.  A pointer  to  a STEP  file,  and  certain 
geometric  constraints. 

Q:  We  want  something  in-between  a pointer  to  a STEP  file  and  certain  geometric  constraints 
for  interference  checking  and  packaging  problems. 

Q:  A user  group  on  one  side  could  type  in  requests,  send  them  to  a set  of  suppliers,  and  then 
they  say,  “yes,  here  it  is,  here  are  the  characteristics,  here’s  a picture”,  and  so  forth. 

Q:  We  need  constraint-based  queries  to  the  database.  The  information  should  be  structured  in 
a format  to  be  queried,  a way  to  get  to  the  information  without  getting  too  much  detail. 

Q:  Pick  whatever  five  parts  you  think  meet  your  requirements,  send  questions  to  suppliers 
asking,  “do  they  meet  it?’ 

Q:  These  constraint-based  queries  should  be  summary/abstracting/derived  views  based  on  the 
STEP  model:  “data  needs”. 

Q:  We  need  more  than  a geometric  model  of  a motor.  For  example,  we  need  key  surfaces, 
torquer’s  footprint,  performance  attributes,  an  idea  of  the  connections,  behavior,  and  functionality. 

Q:  There  is  no  functionality  in  STEP.  You  need  to  pull  it  out  based  on  user  needs,  perhaps 
kinematics  and  dynamics,  perhaps  footprints. 
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Q:  Engineers  at  Boeing  specify  information  by  writing  on  drawings,  making  “buy/build”  deci- 
sions. There’s  a lag  time  between  setting  the  requirements  and  getting  the  order.  The  problem  is 
not  getting  what’s  required,  re-specifying  the  particulars,  maybe  doing  some  testing.  Then  give 
names  of  vendors  who  meet  requirements  to  the  purchasing  department. 

Q:  Supply  chain  is  a major  issue.  Suppose  an  engineer  uses  an  automated  method  to  send  an 
RFQ,  and  the  company  has  internal  processes  to  decide  whom  to  send  an  RFQ...  it  would  help  if 
we  had  testing  information  attached  to  the  supplier. 

Q:  There  is  great  variation  in  what  is  received  in  bearings,  for  example  for  helicopter  engines. 
We  need  industry  standards  for  what  minimum  testing  is  required. 

Q:  Users  sign  proprietary  agreement  and  the  vendor  gives  the  data. 

Q:  Should  we  pick  a test  part  for  the  database? 

Q:  Bearings,  gears,  hubs,  parts  of  drive  chain. 

Q:  70%  of  the  cost  of  a missile  is  the  gimbal,  and  all  the  various  components  that  go  in  the 
gimbal,  including  gyros,  and  focal  point  arrays. 

Q:  There’s  a lot  of  overlap  in  the  ways  Boeing  and  Lockheed-Martin  do  this. 

Q:  A design  repository  should  be  a collection  of  all  this  information;  electrical  catalogs;  per- 
haps search  engines  for  historical  databases,  other  people’s  databases,  or  CAD  files.  The  big  issue 
is  accessing  the  information;  we  already  have  the  information. 

Mr.  Barbieri:  So  far,  there  are  three  main  ideas.  A commercial  off-the-shelf  (COTS)  data- 
base, a national  research  database,  and  a national  material  database. 

Q:  Should  we  have  a common  repository  for  designs,  not  just  design  parts? 

Q:  That  would  most  likely  be  internal. 

Q:  There  are  some  obstacle  issues:  taxonomy  of  parts  of  assemblies,  design  artifacts — the 
physical  things  that  result  from  manufacturing  processes. 

Q:  There  should  be  a common  classification.  For  example,  an  angle  is  different  from  a ro- 
tor— how?  There  need  to  be  umbrella  concepts. 

Q:  There  are  two  issues.  One,  we  need  an  overall  tree  structure  for  assemblies,  subassem- 
blies, and  parts.  Two,  what  characteristics  and  details  should  be  at  each  node  of  the  tree. 

Q:  Typically,  airframe  drawings  are  owned  by  the  U.S.  Government,  except  in  the  case  of 
McDonnell-Douglas.  It  is  up  to  the  government  to  decide  who  has  access. 

Q:  If  this  information  was  used  to  build  the  F-18,  can  they  give  it  to  the  F-22  team? 

Q:  A classification  system  implies  a way  of  searching,  but  all  people  have  their  own  ontolo- 
gies. 

Q:  We  need  a translation  between  one  ontology  and  another. 

Q:  Should  there  be  one  large  database  with  a standardized  format?  Or  should  there  be  many 
databases  with  one  information  broker  that  interacts  with  the  user,  and  is  smart  enough  to  interact 
with  different  databases. 

Q:  There  are  projects  at  Stanford  University,  University  of  Southern  California  Information 
Sciences  Institute,  and  Microtheories  working  on  an  information  broker. 

Q:  You  could  tell  a central  information  broker  what  your  representation  is. 

Q:  Does  a broker  have  a taxonomy  in  its  head? 

Q:  There  are  two  different  problems:  One,  a taxonomy  for  artifacts  and  design  so  that  we  can 
share  design  data  with  our  partners.  This  involves  no  ambiguity.  It  solves  a design  problem. 
Two,  an  information  broker  so  that  we  can  find  out  what  suppliers  can  supply  apart.  This  involves 
some  ambiguity.  It  answers  a resource  discovery  problem.  These  are  two  fundamentally  different 
kinds  of  searching. 

Q:  Design  at  different  levels  of  detail. 

Q:  If  you’ve  done  searches  of  bearing  manufacturer  databases,  you  can  put  the  design  in  your 
overall  design. 

Q:  In  the  COTS  database,  put  the  minimum  information.  When  you  get  a query  from  a cus- 
tomer, you  get  more  information. 

Q:  Do  we  need  an  all-encompassing  taxonomy,  or  is  that  not  realistic? 

Q:  The  primary  goal  of  a central  database  is  to  match  up  buyers  with  suppliers. 
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Q:  Isn’t  this  what  we  already  have?  People  doing  inventory  management  have  on-line  catalogs 
of  products.  Many  organizations  do  things  this  way,  even  though  there  are  no  standardized  se- 
mantics. 

Q:  Standardized  semantics  would  help  small  businesses,  who  don’t  have  inventory  manage- 
ment, more.  Chinook  was  more  than  60%  supplied  by  outside  vendors.  The  777  was  more  than 
50%  supplied  by  outside  vendors. 

Q:  Lockheed-Martin  Orlando  could  say:  “You  want  to  do  business  with  us?  Put  data  in  this 
database,  here’s  the  template.” 

Q:  I hope  all  of  Lockheed-Martin  would  do  this,  and  I dream  that  all  of  DoD  would. 

Q:  But  you  need  to  be  able  to  get  people  who  aren’t  already  doing  business  with  you. 

Q:  I speak  in  favor  of  one  massive  database.  The  information  broker  has  its  own  ontology, 
and  knows  about  other  ontologies.  It  has  a model  of  confidence  of  each  database,  and  knows 
which  supplier  is  possibly  capable  of  supplying  a part. 

Q:  The  information  broker  should  be  capable  of  formulating  catalog-specific  queries,  combin- 
ing query  results  into  a summary,  and  perhaps  asking  the  user  for  more  information. 

Q:  What  if  you  have  to  completely  design  in-house,  no  OEM,  no  off-the-shelf?  Could  you  use 
a lessons-leamed/design-intent  database?  It  would  be  internal  to  the  company,  and  capture  the 
experience  of  designers  who  retire  or  quit.  The  experience  would  include  the  process,  the  result, 
and  the  knowledge  used  to  make  the  decision.  What  parts  can  be  made  in-house,  and  what  parts 
can  be  outsourced. 

Q:  Find  some  way  to  extract  value  from  completed  designs,  or  at  least  as-you-go-along  de- 
signs. 

Q:  NIST  could  come  up  with  a template  for  a design  diary,  using  knowledge-based  engineer- 
ing paradigms. 

Q:  Parametric  description  of  a solid  model  expresses  simple  design  intent. 

Q:  What’s  more  complicated  is:  here  is  this  bearing,  here  is  why  it  was  chosen,  here  are  the 
characteristics  that  met  particular  requirements. 

Q:  This  NIST  document:  for  every  design,  you  fill  it  out  and  save  it.  It  captures  design  ration- 
ale. 

Q:  This  is  a difficult  problem — Fund  this  research! 

Q:  Every  organization  and  designer  has  her  or  his  own  way  of  doing  design.  What  mechanism 
will  fit  in  well? 

Q:  You  have  to  support,  say,  stress  analysis,  material  analysis,  and  a standard  format  to 
document  the  design. 

Q:  Capturing  style  of  design  for  successful  designers  seems  important.  Parse  the  design  itself, 
not  just  the  processes. 

Q:  Style  can  be  parsed  out  of  the  design.  Decision  cannot:  what  trade  studies  did  you  do? 
Why  did  you  decide  “no”  on  this?  It  could  just  be  because  a part  was  temporarily  unavailable  from 
the  supplier. 

Q:  Suppose  we  had  a Disciplined  Design  Diary.  Would  it  work?  Would  a designer  use  it? 
Software  engineers  don’t. 

Q:  If  you  asked,  “Why  did  you  pick  that  bearing?”,  the  answer  would  be,  “We  had  require- 
ments, this  is  how  we  met  them.”  Other  things  may  not  be  as  quantifiable,  but  this  is  a start. 

Q:  There  exists  a tool  called  the  Multidisciplinary  Engineering  Collaborative  Environment  at 
Lockheed-Martin  Palo  Alto.  It  captures  some  design  intent;  it’s  an  engineering  notebook. 

Q:  I don’t  like  STEP.  It’s  not  mature  enough. 

Q:  We  want  to  automatically  put  together  commercial  packaging  problems. 

Q:  They’re  developing  a commercial  package  at  Carnegie  Mellon  University. 

Q:  There’s  an  incredible  DARPA-funded  project  at  Massachusetts  Institute  of  Technology. 
They  have  a two-dimensional  mechanical  design  switch  with  two  or  three  kinematic  motors.  The 
project  is  intended  to  capture  design  intent.  It  could  divorce  most  of  the  geometry  from  the  design 
intent  and  it  could  look  at  different  configurations  in  an  automated  way.  It  automatically  generated 
eight  different  designs  that  did  the  same  thing.  I want  research  like  that  to  be  funded.  One  might 
call  it  “design  generation  tools”.  It  parsed  a two-dimensional  drawing  to  come  up  with  design  ra- 
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tionale,  which  included  very  little  spatial  information.  It  did  not  include  the  traditional  notions  of 
design  parameters,  but  rather  conceptual  design  intent. 

Q:  I use  grammars  (symbolic  reasoning)  to  start  from  a functional  representation.  I automati- 
cally generate  designs  to  make  carts  from  Erector  Sets.  If  there  were  a commonly  agreed-upon  set 
of  functions  that  mechanical  systems  perform,  this  research  would  not  be  stalled.  I need  a general 
set,  for  a larger  domain. 

Q:  Most  of  the  information  is  not  in  design  geometry.  We  understand  that  a motor  is  a motor, 
not  a heater,  even  though  it  generates  heat.  Geometry  is  a summary,  but  there  are  other  views  of 
data. 

Q:  Production  rules  describe  what  is  of  interest  to  you. 

Q:  Start  from  intent.  I want,  for  example,  transformational  motion. 

Q:  What  the  Massachusetts  Institute  of  Technology  researcher  did  was  to  use  a sketch  pad  for 
creating  the  design,  based  on  design  intent,  perhaps  via  a semantic  net. 

Q:  The  requirements  for  such  a project  include  a fixed  information  packaging  scheme  that  de- 
scribes how  information  and  functionality  are  modeled. 

Q:  There  needs  to  be  a standardization  of  design  requirements.  An  external  regulatory  stan- 
dardization, and  internal  standardization  of  processes,  centers  of  excellence,  and  business  practice. 

Q:  There  was  a requirement  that  cabin  door  don’t  implode  under  pressure.  This  implied  that 
they  open  outward.  Boeing  thought  that  opening  outward  was  a requirement,  but  it  wasn’t. 

Q:  It  is  important  to  divorce  design  intent  and  functionality  from  geometry. 

Q:  The  Jami  Shah  paradigm  is  to  have  multiple  variants  of  a particular  design,  and  to  map  be- 
tween them  based  on  design  primitives;  how  they  are  instantiated,  and  what  the  relations  between 
them  are. 

Q:  We  need  to  get  concrete  stuff  done  with  STEP.  Turn  up  the  heat  on  them,  maybe  give  them 
a deadline. 

Q:  We  have  to  transfer  from  CAD  system  A,  say  ProE,  to  CAD  system  B,  say  I-DEAS  Master 
Series.  I wish  you  could  transfer  intelligent  geometry:  features  and  the  relationship  between  them. 

Q:  I have  eight  applications.  If  I am  to  automate  them,  I need  a standard  to  drive  them  all. 

Q:  Vendors  have  nothing  to  work  with.  We  need  a standard  for  portable  capture  and  exchange 
of  feature  information. 

Q:  That  is,  we  need  a completed,  coherent,  complete  standard  that  covers  all  bases.  Some  APs 
are  still  in  draft  stages.  They  need  to  be  completed. 

Q:  Industry  must  push  vendors  to  use  STEP. 

Q:  DARPA  hired  a Cambridge  firm  to  answer  the  question:  why  have  the  circuit  board  design- 
ers performed  so  well?  Their  design  process  is  ten  times  faster!  The  answer:  they  do  two- 
dimensional  or  two-and-a-half-dimensional  design.  Mechanical  design  is  three-dimensional.  We 
need  more  research  in  three-dimensional  packaging  to  produce  commercial  codes  based  on  design 
intent. 

Mr.  Barbieri:  Now  we  need  to  pull  these  together  into  a purpose,  an  approach,  and  some 
problems.  Our  outline: 

1.  There  should  be  a universal  National  Material  Database  that  includes  standard  information 
on  any  type  of  material  that  meets  minimum  testing  procedures  set  by  NIST.  This  infor- 
mation should  include  a “pedigree”:  where  the  data  came  from  and  who  did  the  testing. 
This  information  should  also  describe  how  the  material  is  consistent  with  ASTM  standards. 

2.  There  should  be  a universal  COTS  (Commercial  Off-The-Shelf)  Database  that  allows  mul- 
tilevel querying,  either  broad  or  specific.  There  should  be  a NIST  database  with  minimal 
information,  and  NIST  standards,  including  normalized  data.  This  database  should  enable 
user  interaction  with  suppliers.  There  should  be  an  information  broker,  an  alternative  to  a 
grand  unified  database  that  goes  to  distinct  databases. 

3.  There  should  be  a standard  for  design  intent  databases,  or  a set  of  ISO  guidelines.  This 
would  be  an  internal  database  that  captured  design  experience:  knowledge,  design  decision 
trail,  design  standards — this  is  the  format  you  use  to  capture  the  information.  NIST  should 
set  up  the  requirements  but  not  the  database  itself.  The  requirements  have  the  same  intent: 
review  the  processes,  trade  studies.  Call  it,  perhaps,  the  “Design  Documentation  System”. 
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4.  There  should  be  a National  Research  Database,  with  a set  of  guidelines  for  documenting 
government  funded  research.  This  should  all  be  accessible  from  a NIST  web  site,  with 
HTML  able  to  be  edited  by  the  people  doing  the  research.  This  database  should  also  con- 
tains requests  for  research,  funded  by  government,  industry,  and  universities.  Ah  of  this 
should  include  point-of-contact. 

5.  STEP  has  been  too  little,  too  late — they’ve  been  working  on  it  for  ten  years.  We  want 
more  of  it  sooner.  STEP  currently  helps  with  about  10%  of  design. 

6.  Research  to  produce  commercial  products  for  3-D  packaging. 
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Breakout  Session  #2 — Database /Knowledge -Base 

Frameworks 


Discussions  summarized  by  Dr.  Ronald  Giachetti  (giachett@cme.nist.gov) 
and  Dr.  Mark  Schwabacher  (schwabac@cme.nist.gov) 
(discussions  done  without  slides) 


Participants: 

• Michael  Case 

• Alexei  Elinson 

• Ronald  Giachetti 

• Sandie  Kappes 

• Pradeep  Khosla  (chair) 

• Tim  Malueg 

• Sham  Navathe 

• Mark  Schwabacher 

• Sharad  Singh 

• Eric  Stephens 

• Eswaran  Subrahmanian 

• Susan  Urban 

The  group  facilitator,  Pradeep  Khosla,  led  us  in  a brainstorming  exercise  to  first  identify  what  the 
elements  of  a design  repository  are.  These  categories  evolved  during  the  session.  For  each  cate- 
gory we  attempted  to  determine  what  the  current  state-of-the-practice  is,  what  laboratory  research  is 
being  performed,  and  what  is  desired  or  needed  for  further  design  repositories.  The  three  catego- 
ries are: 

1 . Functionality 

2.  Content,  structure,  and  capture  of  design  knowledge 

3.  Use  and  deployment 

These  notes  are  intended  to  capture  what  was  said  with  as  little  interpretation  as  possible. 

FUNCTIONALITY: 

• Today 

• Today  we  capture  files  - Eric 

• Capture  design  artifacts  - Michael 

• Library  of  pre-drawn  geometry  (geometric  libraries)  such  as  Bentley  or  AutoCAD 

• Printed  documents  capturing  requirements  - Tim 

• Isolated  information  - Eswaran 

• File  management  systems  - Susan 

• Design  data  management,  configuration  control 

• Physical  automated  design  notebooks  - Susan 

• No  means  of  traversing  repository  or  of  checking  -Alexei 

• Design  prescriptions  available  - Tim 
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• Links  from  CAD  to  relational  databases  for  cost  estimating  - Michael 

• Current  Research  In  Laboratory 

• Object-oriented  databases  (missile  design)  and  assembly  modeling  - Tim 

• Design  artifacts  repository  API  (interface  to  existing  tools)  - Sandie  and  Michael 

• Life-cycle  knowledge  through  constraints  - Ronald 

• Design  process  capture  from  specifications  to  design  "as  done"  -Eswaran 

• Measure  of  design  similarity  (prismatic  approaches)  - Alexei 

• Web-based  hypertext  tools  (intranet  too)  linking  design  documents  - Susan 

• Limited  automation  of  relationships  or  constraints  - Tim 

• Functional  requirement  specification  and  rational  capture  systems  - Michael 

• Future  Needs  and  Desires 

• Standard  interface  - Michael 

• Standard  mechanism  to  implement  repository  (STEP)  - Sandie 

• Draw  functionality  from  existing  database  management  systems,  plus  more.  -Sham 

• Designers  to  dynamically  describe  what  they  are  doing  in  an  unobtrusive  manner  - Su- 
san 

• Uniform  naming  scheme  to  support  queries  - Alexei 

• Possible  integration  of  existing  design  ontologies  - Sham 

• Private  and  public  repositories  in  same  framework  - Eswaran 

• Behavior  representations  at  multiple  levels  of  fidelity.  -Eric 

• Specification  and  automatic  enforcement  of  constraints  -Sham 

• Event  notification.  - Michael 

• Uncertainty  management  (tolerances)  - Eric 

• Short  and  long  transactions  (long  defined  as  do  on  portable  with  no  network)  - Eric 

• Security  and  privacy  issues  addressed  - Sharad 

• UNIX  type  security  read/write/etc.  is  sufficient  ? - Eric 

• Locking  on  attribute  values,  not  just  files  - Sham 

CONTENT,  ITS  STRUCTURE,  AND  ITS  CAPTURE: 

• Today 

• Geometric  files  - Tim 

• Text  files 

• Hypertext  - Michael 

• Point-to-point  translators  for  the  above  3 file  types 

• Process  in  the  form  of  work  instructions  - Eric 

• Content  of  MIME  files:  specs,  requirements,  bill  of  materials,  test  data,  images,  proc- 
ess descriptions,  work  flow 

• Content  of  databases:  materials,  part  numbers,  CAD,  manufacturing  resource  planning 
(MRP),  inventory,  geometry,  spatial  data 

• Hand  populated  - Pradeep 

• Inflexible  process  modeling  tools  - Susan 
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• For  example  IDEFO,  Process  Weaver,  BPWin 

• Static  2D  Structures 

• Shared  Relational  Databases  inferencing/explaining 

• Future 

• Analyzable  process  description/models  and  workflows  functional  representation  - Su- 
san 

• Sharable  design  objects  - Sandie 

• Automated  means  of  data  capture,  e.g.,  optical  character  recognition  - Sharad 

• Requirements  accountably  linked  to  product  and  process  attributes  - Eric 

• Make  explicit  the  knowledge  that  is  implicitly  stored  in  computer  programs  - Mark 

• Multimodal  version  control  management  - Eswaran 

• Linking  process  description  and  design  artifacts  - Susan 

• Economic  and  cost  data  - Sham 

• Multiple  alternatives  for  designs  - Michael 

• Rationale  for  design  decisions  - Susan 

• Inter-  and  intra-project  repositories/dynamic  topologies  - Eswaran 

• Ontologies  for  linking  content  of  different  databases  - Susan 

• Self-describing  data  objects  - Sham 

• Use  of  object  request  brokers  (ORB)  for  communication  between  distributed  data 
sources  and  tools 

• Dynamically  extensible  schemes 

• Active  database  concepts  (event/condition/action  rules) 

• Interoperability  (between  heterogeneous,  multimodal  database  management  systems) 

USE  AND  DEPLOYMENT: 

• Today 

• Expensive  discovery  of  already  existing  information  - Michael 

• Manual  processes  - Tim 

• Licensing  of  CAD  tools  is  author  only  - Eric 

• Isolated  and  ad-hoc  implementation  of  repositories  with  incompatible  interfaces  - 
Sharad 

• Poor  human-systems  interface  - Pradeep 

• Future 

• Ease  of  use  and  client-independent  human-system  interface  (HSI)  - Pradeep 

• Tools  viewed  as  service  rather  than  resource  - Eric 

• Scaleable  in  users  and  repositories  without  performance  degradation  - Pradeep 

• Standards  for  federation  of  repositories  - Michael 

• Methods  for  reuse  of  design  histories  - Susan 

• Methodology  for  development  and  deployment  of  repositories  - Eswaran 

• Navigation  across  repositories 
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Breakout  Session  #3 — Standards  for  Information 
Modeling/Knowledge  Representation 

Discussions  summarized  by  Dr.  PVM  Rao  (pvmrao@cme.nist.gov) 
(discussions  done  without  slides) 


Participants: 

• Mike  Benoist 

• Scott  Chase 

• Kim  Cobb 

• Edward  Harter 

• John  Josephson 

• Linda  Lawrie 

• Doug  Peter 

• PVM  Rao 

• Ram  Sriram  (chair) 

• Simon  Szykman 

• David  Thompson 

• Philip  Tsung 

• Peter  Will 

Most  of  the  participants  pointed  out  that  current  industrial  practice  for  product  design  is  cen- 
tered around  commercial  CAD  systems  and  not  product  data  standards.  In  the  electro-mechanical 
product  domain  the  standard  of  primary  interest  is  ISO  10303  or  STEP.  It  was  pointed  out  that  use 
of  STEP,  particularly  AP  (application  protocol)  203  is  presently  restricted  to  exchange  of  geometric 
data  from  one  CAD  system  to  another.  In  practice,  it  is  still  not  being  used  for  the  purpose  of 
common  product  data  sharing.  There  were  many  reasons  pointed  out,  which  are  listed  below. 

• Representing  constraints,  parametric  information,  features,  tolerance  information  etc.  in  the 
present  version  of  STEP  is  still  not  possible. 

• Reliable  STEP  translators  for  various  CAD  systems  are  not  yet  available.  Existing  ones  often 
result  in  the  loss  of  information.  One  of  the  issues  mentioned  in  this  regard  is  the  problem  of 
geometric  precision. 

• Tools  for  representing  a product  as  a system  of  components,  representing  product  assemblies, 
and  representing  key  components  in  the  product  are  not  available  in  either  STEP  or  STEP 
translators. 

• Strict  deadlines,  together  with  availability  of  some  reliable  translators  from  some  CAD  systems 
to  others,  have  allowed  people  to  avoid  the  use  of  standards. 

• Addressing  integration  issues  with  downstream  applications  (DFx)  is  difficult  at  present.  Spe- 
cific mention  was  made  of  representing  process  data  (manufacturing)  and  computational  fluid 
dynamics  data  (analysis)  in  design. 

• There  is  a lack  of  representations  for  measurement  data,  such  as  that  obtained  from  coordinate 
measuring  machine  (CMM),  and  a mechanism  for  relating  this  data  to  design  process  and  de- 
sign data. 
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In  summary,  most  of  the  people  felt  the  real  need  for  speeding  the  process  of  STEP  develop- 
ment to  accommodate  all  the  life  cycle  issues  that  relate  to  design.  The  members  of  the  group  also 
discussed  the  present  practices  of  using  part  libraries  and  material  libraries  for  product  design.  The 
importance  of  standard  libraries  for  design  retrieval  and  redesign  purpose  was  felt  by  most  of  the 
members.  The  upcoming  standard  ISO  13584  or  P-Lib  was  mentioned  by  one  of  the  members. 
Unavailability  of  an  established  standard  for  representing  part  libraries  forced  people  to  re-design 
the  same  component  rather  than  extracting  the  same  from  previous  designs.  Many  members  also 
indicated  a need  for  fast  retrieval  systems  and  retrieval  systems  based  on  function. 

Members  felt  the  need  for  reliable  tools  and  standards  for  representing  product  function,  prod- 
uct behavior  and  conceptual  geometries  for  design.  Another  interesting  aspect  of  the  discussion 
was  the  need  for  tools  linking  conceptual  design  with  detailed  design. 

Representing  design  information  of  electronic  products  is  another  subject  that  was  discussed. 
It  was  pointed  out  that  the  problems  of  representing  design  information  in  this  domain  are  less  dif- 
ficult due  to  simpler  product  geometries  as  well  as  because  of  strong  coupling  between  product 
form  and  function. 

Information/knowledge  representations  for  architectural  design,  and  the  need  for  standards  in 
this  area  were  mentioned.  Some  of  the  standards  initiatives  undertaken  in  this  direction  were  dis- 
cussed in  some  detail. 
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Rapid  Design  Exploration  and  Optimization  (RaDEO) 

Mr.  Kevin  Lyons,  DARPA  (klyons@darpa.mil) 

(14  slides  start  after  page  330) 


Mr.  Lyons  started  by  noting  that  the  name  of  the  MADE  program  had  been  changed  to  RaDEO 
(Rapid  Design  Exploration  and  Optimization).  The  concept  of  a design  repository  is  a key  issue 
for  RaDEO.  The  marketplace  is  changing;  teaming  between  companies  is  encouraged  or  required 
to  remain  competitive.  We  are  getting  more  computer-literate  suppliers,  but  they  have  incompatible 
systems.  Merging  corporations  can’t  communicate. 

On  the  “Program  Goal”  slide,  all  of  the  “ability  to...”  points  were  discussed  in  various  break- 
out sessions:  get  a better  way  to  look  at  current  databases,  identify  the  problem,  and  pull  out  solu- 
tions. The  “Realization  of  a Seeker  System”  slide  describes  how  a conceptual  optics  design  finds 
its  way  into  different  applications.  The  “System-Centric  Design”  slide  expresses  the  idea:  “I  am  a 
gimbal  designer  and  all  else  focuses  around  there,”  or  “I  am  an  airfoil  designer,”  or  something 
else. 

RaDEO  is  structured  around  27  contractors  in  four  problem  areas.  One  focus  area  is  Design 
Exploration  and  Advanced  Design  Representation.  We  want  to  store,  retrieve,  and  index  all  differ- 
ent types  of  design  information.  We  need  to  do  a better  job  of  structuring  the  information  to  allow 
intelligent  queries.  Another  focus  area  is  Multi-Disciplinary  Optimization  and  Simulation.  This 
involves  ways  to  balance  trade-off  analysis:  weighting,  schemes  based  on  marketplace  concepts, 
and  other  ways.  A third  focus  area  is  Integration  Frameworks.  This  is  “bare-bones”  work:  very 
early  conceptual  frameworks.  The  final  focus  area  is  the  designers  interface. 

Information  is  the  power  of  a design  team.  The  more  information  you  have,  the  more  power 
you  have.  There  is  a lot  of  historical  information  that  you  cannot  ignore  in  the  present  enterprise. 
RaDEO  has  several  efforts  involved  with  capturing  design  intent  in  various  ways  and  aspects. 
STEP  is  of  some  help,  but  not  enough. 

Intelligent  querying  involves  the  retrieval  of  information.  Nobody  lacks  information,  they  only 
lack  a way  of  accessing  it.  We  need  to  narrow  the  scope  of  the  information  to  present  it  to  the  en- 
gineer in  a meaningful  way.  We  need  ontologies  and  taxonomies.  We  want  to  decompose  sys- 
tems into  common  structures.  We  hope  this  fundamental  work  will  have  huge  benefits. 

We  are  focusing  on  real  demos  with  DoD  impact.  Our  customer  sets  include  missiles,  aircraft, 
and  helicopters.  We  form  contractors  into  demo  groups,  which  we  pull  from  all  categories,  and 
they  take  the  systems  to  the  next  level. 

A workshop  participant  interrupted  Mr.  Lyons  to  ask  how,  with  27  separate  contractors,  did  he 
as  program  manager  pull  it  all  together.  Mr.  Lyons  answered  that  he  works  directly  out  of  the  pro- 
gram office  with  the  aid  of  a number  of  agents  in  other  government  agencies  that  help  manage  indi- 
vidual projects.  Also,  demo  groups  take  ownership  of  the  systems. 

Mr.  Lyons  concluded  by  directing  participants  to  the  DARPA  web  page,  for  solicitations  under 
the  Information  Systems  Office  for  High-Performance  Knowledge  Bases  (HPKB),  BAA  (Broad 
Agency  Announcement)  96-43. 
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High-Performance  Knowledge  Bases  (HPKB) 

Dr.  David  Gunning,  DARPA  (dgunning@darpa.mil) 
(16  slides  start  after  page  345) 


Dr.  Gunning  began  his  talk  by  saying  that  there  were  historical  reasons  for  the  High- 
Performance  Knowledge  Bases  (HPKB)  name.  The  HPKB  goal  is  very  specific  and  not  neces- 
sarily achievable.  Today  you  build  a knowledge  base  with  two  thousand  to  ten  thousand  axioms, 
rules,  and  frames,  and  it  takes  great  manual  effort.  HPKB  wants  to  move  to  ten  thousand  to  a 
hundred  thousand  axioms,  rules,  and  frames,  giving  in-depth  coverage  of  the  entire  domain. 

What  is  a knowledge  base?  It  is  something  more  declarative:  axioms,  or  statements  in 
some  declarative  language.  Domain  theories  could  be  formulated,  for  example,  in  predicate  calcu- 
lus. But  this  is  just  an  example,  it  is  not  a necessity.  We  want  to  be  able  to  compose  and  check 
knowledge  bases.  There  are  libraries  of  reusable  information,  especially  libraries  of  domain 
knowledge. 

The  envisioned  knowledge  base  development  is  a three-step  process.  First,  in  Foundation 
Building,  one  needs  tools  to  build  and  reuse  libraries  of  foundation  knowledge.  One  also  needs 
tools  to  compose  and  edit  these  libraries,  to  quickly  compose  a knowledge-base  framework.  Sec- 
ond, in  Knowledge  Acquisition,  it  is  best  to  use  machine  learning  or  natural  language  processing  to 
fill  up  the  knowledge  base.  Then,  in  Efficient  Problem  Solving,  do  more  efficient  reasoning,  use 
inference  methods,  or  transform  knowledge  into  compiled  modules.  The  BAA  is  looking  for  tech- 
nology for  each  of  the  three  steps,  and  for  integration.  The  four-year  goal  is  complete  systems. 

Foundation  Building  involves  very  large  lexicons,  such  as  WordNet.  These  lexicons  should 
be  broad,  not  deep.  There  should  be  a library  of  in-depth  theories  of  concepts  such  as  time  and 
space.  These  may  be  present  in  different  ways.  There  should  be  a library  of  problem  solving 
strategies.  The  user  should  be  able  to  quickly  compose  ontologies  and  theories  into  a unified  tool. 

In  Knowledge  Acquisition,  we  want  to  automatically  generate  a user  interface  so  that  a non- 
knowledge engineer  can  enter  the  knowledge.  We  want  to  import  knowledge  from  lexicons  and 
dictionaries,  and  extract  information  from  the  text  with  natural  language  processing  or  machine 
learning.  These  tools  enable  domain  experts  to  collaborate  to  extract  and  define  domain  knowl- 
edge. 

Efficient  Problem-Solving  technology  is  technology  we  hope  to  build  and  integrate. 

Our  approach  is  shown  on  the  “Development  Approach”  slide.  The  program  should  go 
through  these  steps  in  some  sequence.  In  step  5,  products  should  become  DARPA  application 
products.  We  hope  that  HPKBs  will  have  general  use  for  many  domains.  But  for  now,  they  are 
largely  intended  for  military  use:  battlefield  awareness,  command  and  control,  and  logistics.  Peo- 
ple in  DARPA  are  interested  in  design  domains,  but  are  bent  to  military  applications. 

DARPA  is  looking  for  people  to  define,  manage,  and  maintain  challenge  problems.  First,  they 
ask  developers  to  build  knowledge  bases  for  challenge  problems,  and  see  how  quickly  they  can  do 
that.  Second,  they  need  some  more  broad-but-shallow  challenge  problems  that  are  more  generally 
applicable.  The  Challenge  Problem  Process  starts  with  the  receipt  of  terminology,  ontology,  and 
expertise  about  the  domain.  Then,  you  have  one  month  to  build  the  knowledge  base.  DARPA  is 
soliciting  approaches  to  define  challenge  problems,  as  well  as  technology  itself.  Challenge  prob- 
lems should  not  allow  a shortcut  answer. 

BAA  96-43  is  calling  for  proposals  in  two  areas.  5 December  1996  was  the  proposal  deadline, 
and  Dr.  Gunning  was  looking  forward  to  an  interesting  set  of  proposals.  He  felt  that  it  was  time  to 
look  at  knowledge  base  technology  again. 

A brief  question-and-answer  period  followed  Dr.  Gunning’s  talk.  Questioners  are  identified 
by  number. 
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Ql:  Is  the  end  user  aware  of  using  a knowledge  base? 

A:  Not  necessarily. 

Ql:  Is  it  more  ubiquitous? 

A:  Yes. 

Ql:  Obviously  you  are  using  an  expert  system,  should  you  make  the  user  less  aware  of  using 
it? 

A:  Yes.  Part  of  efficient  problem  solving  is  packaging  data  to  fit  it  into  another  application. 

Ql:  My  background  is  in  control  theory.  I spent  significant  effort  in  a knowledge  base  for 
real-time  control  with  commercial  neural  network  and  fuzzy  logic  systems.  The  real  problem  is 
integrating  lower-level  components  into  larger  systems.  The  problem  with  operations  in  military  is 
that  high-level  logic  has  seamless,  useful  integration.  The  declarative  approach  doesn’t  mention 
the  evolution  component,  or  composability  into  larger  models.  It  describes  the  real  world  as  a set 
of  rules. 

A:  Agreed. 

Ql:  Are  you  looking  for  evolution  as  well  as  representation? 

A:  Yes.  Integrate  knowledge  at  different  levels  of  abstraction.  Declarative  languages  didn’t 
work  well  before,  but  after  new  technology,  it’s  time  to  go  back  and  investigate. 

Q2:  Most  of  the  areas  you  described  are  engineering  and  manufacturing.  How  would  you  as- 
sess a proposal  that  used  a generic  knowledge  base,  with  specific  application  to  engineering  and 
manufacturing? 

A:  That’s  a tough  question.  It’s  a good  idea,  but  we  will  have  to  try  the  tools  against  military 
challenge  problems.  Before  DARPA  reorganized,  the  original  version  of  the  program  included 
both  design  and  battlefield,  and  the  design  went  to  another  office.  At  least  80%  of  the  effort  must 
be  on  the  battlefield. 
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How  Does  a Standard  Become  a Standard? 

Ms.  Sharon  Kemmerer,  NIST  (kemmerer@cme.nist.gov) 
(3  slides  start  after  page  362) 


Dr.  Sriram  introduced  Ms.  Kemmerer  as  a STEP  expert  who  would  give  a presentation  on  how 
a standard  becomes  a standard.  Ms.  Kemmerer  started  by  describing  ISO,  the  International  Orga- 
nization for  Standardization.  ISO  is  in  charge  of  all  non-electrotechnical  standards.  It  had  85 
member  countries  at  the  end  of  1995.  The  EEC  (International  Electrotechnical  Commission)  is  in 
charge  of  all  electrotechnical  standards.  It  had  50  member  countries  at  the  end  of  1995.  The  host 
organizations  for  both  ISO  and  IEC  reside  in  Geneva.  You  can  check  out  their  web  sites  for  more 
information. 

Say  that  a country  comes  forward  with  a new  work  item.  The  active  liaison,  or  a technical 
organization,  needs  to  come  forward  with  a standard.  They  need  at  least  two  pages  to  describe  the 
impact,  or  a full  standard  if  it  needs  to  be  fast-tracked  through  the  international  community. 

A new  work  item  (NWI)  proceeds  through  the  following  stages: 

• Five  of  nineteen  “P  members” — actively  involved  countries — within  ISO  TC184/SC4  must 
actively  participate  in  the  development.  Ten  of  nineteen  must  approve  the  statement  of  impact. 
There  is  a three-month  ballot  cycle  to  subcommittee  members,  which  usually  generates  some 
comments. 

• Upon  approval  of  NWI  working  draft  is  created.  Most  ISO  standards  run  50- 1 50  pages.  Most 
Subcommittee  4 (SC4)  standards  are  longer,  running  1500-2000  pages. 

• Next  comes  the  Committee  Draft  (CD)  cycle.  There  is  a four-month  cycle  to  subcommittee 
members,  which  usually  generates  many  more  comments. 

• Then,  there  is  a Draft  International  Standard  (DIS),  where  members  make  sure  that  recom- 
mended technical  changes  have  been  implemented.  There  is  a five-month  ballot  cycle  to  all  ISO 
members.  A two-thirds  majority  of  all  voting  members  must  approve. 

• Next,  there  is  a Final  Draft  International  Standard  (FDIS).  No  technical  comments  are  made  at 
this  point — only  editorial  comments.  Finally,  after  a two-month  ballot  cycle  to  all  ISO  mem- 
bers, it  becomes  an  International  Standard. 

A question-and-answer  period  followed  Ms.  Kemmerer  ’s  talk.  Questioners  are  identified  by 
number. 

Ql:  I have  a very  specific  question:  did  AP  209  just  become  DIS? 

A:  It  is  currently  in  the  CD  stage.  They  are  incorporating  comments.  It  may  have  already  been 
approved  to  become  DIS. 

Ql:  Do  you  have  to  develop  test  cases? 

A:  A resolution  specific  to  SC4  says  that  we  must  have  proof  of  validation.  Also,  an  abstract 
test  suite  must  support  DIS  in  SC4.  STEP  is  one  of  four  ISO  standards  that  SC4  is  working  on. 
The  others  are  a standard  for  parametrics,  a suite  of  standards  for  parts  libraries,  and  a suite  of 
standards  for  manufacturing  management  data. 

Q2:  DoD  requires  us  to  cut  our  life-cycle  costs  in  half.  Can  we  pass  that  on  to  you? 

A:  Standards  will  help. 

Q2: 1 agree,  but  standards  aren’t  doing  enough. 

A:  We’re  working  on  application  protocols. 

Q2:  It  seems  as  if  you  have  no  goals  for  a particular  date. 

A:  Our  goals  are  to  move  from  an  NWI  to  a First  Working  Draft  within  six  months,  then  to  a 
CD  within  eighteen  months,  and  then  to  an  FDIS  within  three  years.  But  our  goals  are  slipping  in 
fifty  of  our  programs.  Standards  can  be  subject  to  cancellation  or  reconfirmation. 
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Q3:  This  morning,  the  FDA  (Food  and  Drug  Administration)  said  that  you  cannot  put  the  word 
“lowfat”  on  2%  milk,  you  must  instead  use  “reduced  fat.”  What  is  your  current  policy  on  sup- 
porting standards?  How  can  you  help  vendors  play  by  the  rules? 

A:  This  is  a voluntary  standards  process.  In  most  of  the  world,  standards  are  driven  and 
funded  by  governments.  The  U.S.  is  mostly  industry-driven  and  industry-funded. 

Q3:  Is  there  ongoing  activity  for  independent  testers  to  verify  performance? 

A:  Yes.  NIST  offers  a beta  testing  suite  for  AP  203.  ProSTEP  of  Germany  has  an  interoper- 
ability testing  program. 

Q4:  So  you’re  not  analogous  to  the  FDA? 

A:  Unlike,  for  example,  safety  standards,  the  role  of  the  government  for  product  data  stan- 
dards is  not  that  of  a regulatory  agency  but  more  of  a neutral  facilitator  for  standards  development. 
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Presentation:  Breakout  Session  #1 — Industry  Perspective 

Dr.  Michael  Barbieri,  Lockheed  Martin  (MPBarbieri@lmtas.lmco.com) 

(3  slides  start  after  page  366) 


Industry  needs: 

• NIST  Material  Database  with  data  summary  of  materials. 

• COTS  Database  with  the  ability  to  send  email  to  suppliers;  NIST  should  supply  the  format. 

• Information/Design  Broker  to  handle  different  terminology  for  the  same  things,  and  break 
down  barriers. 

• Design  intent/diary  format,  an  “ISO”  format  for  saving  information. 

• A national  research  database.  There  is  much  duplicated  research.  There  needs  to  be  a place  for 
researchers  to  input  data,  and  find  out  about  Points  of  Contact. 

• Speed  up  STEP. 

• Commercialization  of  three-dimensional  packaging. 
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Presentation:  Breakout  Session  #2-DatabaselKnowledge-Base 

Frameworks 

Dr.  Pradeep  Khosla,  Carnegie  Mellon  University  (pkk@cs.cmu.edu) 
(presentation  given  without  slides) 


Dr.  Khosla  said  that  one  positive  note  was  that  most  of  the  topics  from  the  breakout  session 
were  discussed  by  Dr.  Gunning  in  a different  context.  The  fundamental  question:  What  is  a design 
repository?  It  should  have  functionality,  content,  structure,  use,  and  deployment. 

Today,  we  use  engineering  practice,  and  research  laboratory  practice.  Tomorrow  (in  five  to  ten 
years),  where  would  we  like  to  be? — mostly  from  a research  point  of  view,  although  industry  is 
involved  in  use  and  development. 

For  example,  today  we  have  file  capture.  Tomorrow,  we  would  like  to  have  integration  with 
design  repositories.  One  issue  is  integrating  multiple  repositories  of  the  same  type.  Another  is  a 
human-system  interface  to  databases.  We  need  to  populate  and  operate  databases  efficiently. 

There  was  a National  Academy  of  Sciences  report  on  Information  Technology  in  Manufactur- 
ing— for  information,  contact  Dr.  Will  (will@isi.edu).  This  is  a resource  worth  looking  at. 
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Presentation:  Breakout  Session  #3 — Standards  for  Information 
Modeling/Knowledge  Representation 

Dr.  Simon  Szykman  (szykman@cme.nist.gov) 

(3  slides  start  after  page  369) 


Current  practices  involve  some  use  of  standards  in  industry.  Sometimes  there  are  translator 
problems.  One  issue:  there  is  no  data  sharing  yet.  There  are  many  database  issues,  and  there  are 
barriers  to  use  of  standards,  including  slow  STEP  development. 

There  are  a number  of  needs  and  recommendations.  Immediate  needs  involve  improving  stan- 
dards for  common  design  and  design-related  activities  in  the  short  term.  Priorities  include  DEM 
(Design  For  Manufacture)  standards  to  represent  information  about  manufacturing  in  the  context  of 
both  design  and  manufacturing  processes. 

There  are  geometric  precision  problems,  in  that  there  are  mathematical  precision  differences 
across  CAD  systems.  Information  issues  include  standards  to  help  with  conceptual  design,  analy- 
sis, DFM  and  DFx.  Design  retrieval  and  redesign  is  another  concern;  today  we  often  redesign 
existing  parts  because  it’s  easier  than  looking  up  an  old  design. 

There  are  long-term  issues  as  well.  We  need  standards  and  integration  for  conceptual  designs. 
We  need  to  represent  not  just  geometry,  and  not  just  individual  parts.  There  are  multidisciplinary 
issues  that  become  important  with  multiple  disciplines,  but  that  are  not  commonly  addressed  be- 
cause they  don’t  arise  in  a single  discipline.  Ontologies  are  very  important  as  well.  In  electronics, 
name,  form  and  functionality  are  more  strongly  linked  than  in  mechanical  design  and  manufactur- 
ing. Finally,  there  is  a new  set  of  issues  associated  with  the  use  of  the  Internet  as  a medium  for 
communication. 


58 


Presentation  Slides 
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Welcome  to  NIST 

Dr.  Richard  H.  F.  Jackson,  NIST  (jackson@cme.nist.gov) 


The  summary  for  this  presentation  can  be  found  on  page  11 

20  slides  follow 


61 


> 

o 

"co 

o 

o 

o 

£ 

0) 

m 

• mmm 

i 

Q 

m 

c 

c 

□ E=J 

o 

1— 

m 

© 

jx 

® 

o 

c 

m 

'5) 

c 

■ 

LL 

LU 

S 

I 

u> 

c 

"O 

IH 

co 

3 

JZ 

o 

o 

CO 

■ BHS) 

oc 

3 

C 

CO 

2 

62 


NIST  Functions 
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Advise  industry  and  government  on  scientific 
and  technical  problems. 


NIST  Resources 
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anufacturing  Extension  Quality  Program 

Partnership 
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Provide  fabrication  services  to  NIST. 


Trends  in  Manufacturing 
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AMRF  Project 
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AMRF  Accomplishments 
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Donations  totaling  more  than  $20M 
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Information  Technology  is  the  Key  Enabler 


. . .information-based  manufacturing... 

...manufacturing  that  relies  upon  and  exploits  the  capabilities  available  to  systems 
& processes  through  the  application  of  information  technology  as  a value-added 
resource... 


c 

(A  CD 

1 § 

B E 
i o 

| T3  r 

5 C (0 
ns  CL 


c/> 

C/5 

ga 

w o 
"O  3 
— -O 

o o 
:>  a_ 


' 

W 


fjp 

o 

c 

Wit 

pm 

imm 

3 

m 

o 

£ E 

/ V X ' '/ 

Z: 

= B 

« >* 

S CO 

w 

(0 

o 

(0 

jm\  w. 

3 

o 

Iw 

15 

— O 

CD 

\S: 

O 

T5  o 

f 

fa- 

L. 

C s- 

CD 

ff 

CL 

CD  Q. 

Q 

Information  Technology  & Manufacturing 
Traceability  of  informational  Standards 
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NAMT  Projects 
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Information  Needs  for  Pump  Design 
Dr.  Lalit  Chordia,  Thar  Designs  (chordia@thardesigns.com) 


The  summary  for  this  presentation  can  be  found  on  page  14 

14  slides  follow 
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THAR  DESIGNS 
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THAR  DESIGNS 
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• Incompressible  Liquids  Vs  Compressible  C02 

No  Choice:  But  to  Design 
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Minimize  Dead  Volume: 
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mportance  of  High  Strength  Materials 
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Efficient  Cooling 
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Small  Footprint 
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THAR  DESIGNS 
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Pump  Assembly 
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SERVO  MOTOR 
PUMP  FRAME 
TIMING  BELT 
TIMING  PULLEY 
CAM 

CAM  SHAFT 
ROT.  BEARING  BLOC 
PISTON  HOUSING 
SPRING 

LIN.  BEARING  BLOCK 
SEAL  BACKUP  PLATE 
PUMP  HEAD 
COOLING  TUBES 
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Information  Retrieval  During  Design  of  a Medication  Dispenser 

James  Michael,  Diebold,  Inc. 


The  summary  for  this  presentation  can  be  found  on  page  16 
11  slides  follow  on  six  pages 
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Development:  Initial  Concept 

□ Detailed  Definition 

□ Technology  Search  & Conception  Testing 

✓ Industry  standards  - JCAHO,  ASIS 

✓ Patents,  WWW,  Magazines,  Libraries,  CD’s, 
Conferences,  Seminars,  Med  suppliers 

J*  State  regulations 

j*  Information  Consolidation  / Resource  Links 

James  A.  Michael,  Diebold,  Incorporated  96/11/19  7 


Development:  Detailed  Design 

□ Design  Techniques  - DFx 

□ Part  Availability 

✓ Texts,  Associates,  Self,  Confer,  Seminars,  WWW, 
Technical  knowledge  services,  Corp.  standards 

✓ Product  standards  - safety,  packaging 

✓ Suppliers,  Thompson’s,  WWW 

Ji  CAE  databases,  PDM,  Guidelines 

J*  Information  Consolidation  / Resource  Links 

James  A.  Michael,  Diebold,  Incorporated  96/11/19  8 


James  A.  Michael 
Diebold,  Incorporated 


101 


96/11/19 


Information  Retrieval  During  the 
Design  of  a Medication  Dispenser 


Information  Access 
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■ Access  during  development  was  good 
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Summary 

■ Product  development  successful  with 
current  information  access  methods 

■ With  Information  Consolidation  / Resource 
Links  tied  to  Development  Cycle 

• greater  ease  of  access 

• more  organized  information 

• shorter  development  cycles 

• higher  quality  products  sooner 
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Development  of  an  Adaptive  Modeling  Language  for  Knowledge- 
Based  Engineering  with  Application  to  Interactive  Gimbal  Design 

Dr.  Rich  Zarda,  Lockheed  Martin  (zarda@slr.orl.mmc.com) 


The  summary  for  this  presentation  can  be  found  on  page  18 

16  slides  follow 


104 


m 

c 

o 

« 

3 

E 

°55 

— 

© 

£ 

<D 

if) 

DM086-0001-02 


CO 


Software/hardware  contributions  from  Oracle,  PTC,  SDRC,  AVS,  MSC,  and  HP. 
AML  class-objects  developed  for  optical  design. 

Reviewed  transfer  of  intelligent  parametric  solids. 


gimbal  components. 


Interactive  Gimbal  Design  (IGD) 


Interactive  Gimbal  Design  (IGD) 


a 


i— 


o 


a. 


U) 


± 


± 


Intelligent  Data 

• Previous  gimbal  designs 

• Unified  AML  model 


Technical  Approach 


Oj<o+^ca.Q(Bc/>a><0 


CD 


0 


CD  Mi/  Ik 

c 


WO-l^OQCQO 


LL. 


0 


0 


0 

0 

0 

S3 

■o 

V. 

o 

0 

a. 

4-» 

o 

0 

CL 

g 

(/> 


O 


(0 

■a 

0 

0 

■■■■ 

© 

r 

f" 

© 

0 

g 

a 

o 

8= 

& 

0 

0 

0 

*o 

o 

0 

_c 

a 

o 

Sc 

*— > 
0 

2 

fit, 

Q) 


0 


CO 


CO 


oujco^coh-uja. 


O < Q CO  >»  0 ■*-  0 £ 0 


CD 


DM086-0001-42 


(SSI)  siuopvx 


Interactive  Gimbal  Design  (IGD) 


Reliable  Manufacturing  Costing  Algorithms. 


MADE-IGD  Electro-Mechanical  Gimbal  Subcomponent  Database 
Dr.  Tim  Malueg,  CRC  (tmalueg@hsv.crc.com) 


The  summary  for  this  presentation  can  be  found  on  page  19 
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SAVE:  Simulation  Assessment  Validation  Environment 

Carl  Izurieta,  Lockheed  Martin  (izzy@mar.lmco.com) 


The  summary  for  this  presentation  can  be  found  on  page  20 
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Integrated  Product  Data  Environment  (IPDE) 

Dr.  Ed  Harter,  Boeing  (edward.d.harter@boeing.com) 


The  summary  for  this  presentation  can  be  found  on  page  23 
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Manage  the  Required  Volumes  of  Data  (VLDB  Issues) 
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SDM  Data  Access  Unit 
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SDM  Technology  Issues 
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IPDE  Program 
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That  Spans  Multiple  Domains 

» A Given  Domain  Might  be  Addressed  by  More  Than  One  Data 
Standard  (e.g.,  STEP,  KIF) 


CEM  Vocabulary  Integration 
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Vocabulary  Integration  Issues 
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Design  Data  Treatment  Issues  at  Boeing  Helicopters 

Dr.  Gary  Coen,  Boeing  (gary.a.coen@boeing.com) 


The  summary  for  this  presentation  can  be  found  on  page  24 

5 slides  follow 
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NIST  Design  Repository  Workshop 
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1ST  Design  Repository  Workshop 
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Feature-Based  Design  Storage  and  Retrieval 
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Challenges  for  Design  Repository  Schemata 
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Use  of  Standards  for  Data  Storage  and  Exchange 
Gene  Allen,  The  MacNeal-Schwendler  Corporation  (gene.allen@macsch.com) 


The  summary  for  this  presentation  can  be  found  on  page  28 

8 slides  follow 
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COLLABORATIVE  DEVELOPMENT 
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MODEL ACCURACY 
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Industry  Drivers 


(In-House  Characterization) 


Integrating  a Distributed,  Agile,  Virtual  Enterprise  in  the  TEAM 

Program 

Kim  Cobb,  Lockheed  Martin  (di@ornl.gov) 


The  summary  for  this  presentation  can  be  found  on  page  29 

24  slides  follow 
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Technologies  Enabling  Agile  Manufecturing 


TEAM  Mission 
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Technologies  Enabling  Agile  Manufacturing 
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Scope  and  Alignment  of  TEAM 
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Technologies  Enabling  Agile  Manufacturing 


TEAM  Goals 
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Technologies  Enabling  Agile  Manufacturing 


The  TEAM  Enterprise  Model 
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islrial  Strength  Optimization  at  Boeing,  by  Paul  Davis,  SIAM  News,  Jan  ./Feb.  1996 
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Multiple  Thread  Acceleration 
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Thread  Unification 


268 


A Representation  of  the 
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Actions  Refine  Product  Update  Discipline  Alter  Design 

(Example)  Geometry  Requirements  Goal  , 
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s 797-11,  CONFIGURATION  22 

RADAR  SELECTION 
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I li  5-797-11,  CONFIGURATION  23 

I RADAR  SELECTION 


3:  Implement  design 
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Model-Based  Support  for  Collaborative  Engineering — Focus  on 
Ontologies:  How  Things  Work  Project 

Dr.  Yumi  Iwasaki,  Stanford  University  (iwasaki@ksl.stanford.edu) 


The  summary  for  this  presentation  can  be  found  on  page  35 
6 slides  follow  on  three  pages 
A paper  on  this  topic  begins  after  page  375 
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Model-Based  Support 

Collaborative  Engineering 

Focus  on  Ontologies 


How  Things  Work  project 


Richard  Fikes 
Yumi  Iwasaki 
James  Rice 
Robert  Engelmore 


Todd  Neller 
Tony  Loeser 
Dana  Clarke 
Kentaro  Oguchi 


Knowledge  Systems  Laboratory 
Stanford  University 


Distributed  Collaborative  Design  with  CDME 


Yumi  Iwasaki 

Knowledge  Systems  Laboratory 
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Representation  Layers 


72/2/96 


Knowledge  Systems  Laboratory , Stanford  University 


Domain  Specific  Ontologies 


Knowledge  Systems  Laboratory , Stanford  University 


Yumi  Iwasaki 

Knowledge  Systems  Laboratory 
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Domain  Specific  Ontologies 


Domain  Specific  ontologies 


Knowledge  Systems  Laboratory,  Stanford  University 


Summary 


♦ Support  collaborative  modeling 

♦ Declarative  domain  specific  ontologies 

♦ Global,  high-level  model 

♦ Communication,  coordination 


12/2/96 


Knowledge  Systems  Laboratory,  Stanford  University 


Yumi  Iwasaki 

Knowledge  Systems  Laboratory 
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The  Shared  Design  Manager:  A Repository  for  Integrated  Product 

Data 

Dr.  Susan  Urban,  Arizona  State  University  (s.urban@asu.edu) 


The  summary  for  this  presentation  can  be  found  on  page  36 

7 slides  follow 


282 


283 


NIST  Design  Repository  Workshop  11/15/96 


Objectives 


2.  • • 
5 © 

3 -s 

> CO 
3 c 
i LU 

. O 
3 ~ 

3 © 
'l  T3 
J O 


© CO 

(2  e 

o-g 


2 E 

U>  c 

S S 

£ O 


c 

CD 

°0 

CD 

Q 


c 

o 

0 
■+— » 

c 

CD 


0) 

CL 


0 

0 

0 

-Q 

iS 

-4—1 

cd  co 

0 D 

"O  CO 

05  'to 

CO  ^ 

CO 

CO  CO 

a.  < 
|f)  "D 

1—  C 

CO  CO 


A 

A 


C/D 

'0 

C 

< 

"O 

c 

0 

c 

O) 

*0 

0 

Q 

CD 

C 

o 


CD 

c 

■c  0 
0 CD 

C/D  ”q_ 

iS  'o 

0 sa 

Q Q 


w 

A 


0 
■+— < 

0 

Q 

■~N 

CD 

O O 
> 
O 
± co 

H-  0 

o >> 

H-1  0 

c c 

0 < 

£ 1 

<3^  CD 
CD  •— 

g s 

co  Q 

^ CD 

c ■£ 

o *- 

CO  o 

.§  3 

^ o 

o JZ 

O I- 


✓\ 

A 


284 


Relationships  Between  Units 
of  Functionality  (UoF*) 
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NIST  Design  Repository  Workshop  11/15/96 


Shared  Design  Manag 

Architecture 
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NIST  Design  Repository  Workshop  i 1/15/96 


SDM  Data  Access  Unit 
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SDM  Metadata 
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SDM  Technology  Issues 
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Active  Catalogs:  A Designers  Aid 

Dr.  Peter  Will,  University  of  Southern  California  (will@isi.edu) 


The  summary  for  this  presentation  can  be  found  on  page  37 

17  slides  follow 
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Active  Catalogs: 
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Work  performed  under  DARPA  support 
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Concurrent  Design  Activities 
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Knowledge  about  design,  components, 

& information  consumption  is  critical  for 
reuse  of  designs  & components 
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Engineering  Design-Related  Database  Research  at  Georgia  Tech 

Dr.  Sham  Navathe,  Georgia  Institute  of  Technology  (sham@cc.gatech.edu) 


The  summary  for  this  presentation  can  be  found  on  page  38 

21  slides  follow 

A paper  on  this  topic  begins  after  page  384 
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Voltage  Tables  with  Prototype  columns 

Tables  having  Property  and  Prototype  columns 
(check  for  Property  ==  Voltage) 
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Property  Tables  having 

♦ Voltage,  Prototype  and  Value  columns  (check  for 
Prototype  ==  Battery) 

* Voltage  and  Battery  columns 
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Voltage  Tables  having 

♦ Prototype  and  Value  columns  (check  for 
Prototype  ==  Battery  AND  Value  ==  10) 

♦ Battery  and  Value  columns  (check  for  Value 
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tables  having  Property,  Value  and  Prototype 
columns  (check  for  Property  ==  Voltage  AND  Value  = 


Horn  vf  the  1996  fAympk  Village 
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CORAL  Facts  and  Rules 

LfifsTo (components,  dbl). 
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♦ isAttrib(Db,  Table,  Attri)  :- 

hasAttribs(Db,  Table,  Attribs), 
iselem  (Attri,  Attribs). 
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corresponding  rules  to  check  for  the 
relevant  tables. 
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for  Battery  table  in  db2: 
SELECT  * 

FROM  battery 


Horn  vf  the  1996  Olympic  Village 
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incorporating  joins  within  and  across 


rmvftte  1896  Ob/rnplc  Village 
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♦ Engineering  Systems 

♦ Complexity  of  function,  si 
4-  Application  to  simulation 
4 Proposal  for  cataloging 


Additional  Relevant  Work 
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30  Database  System  for  schema  evolution 
Developed  a flexible  OODBMS 
Evolution  of  classes  automatically  impacts 
evolution  of  instances 


Rapid  Design  Exploration  and  Optimization  (RaDEO) 

Mr.  Kevin  Lyons,  DARPA  (klyons@darpa.mil) 


The  summary  for  this  presentation  can  be  found  on  page  50 

14  slides  follow 
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High-Performance  Knowledge  Bases  (HPKB) 

Dr.  David  Gunning,  DARPA  (dgunnieg@darpa.mlS) 


The  summary  for  this  presentation  can  be  found  on  page  51 
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actions  and  processes 

belief  and  uncertainty 

physical  objects  and  behavior 

other  commonly  used  terms  and  domains 
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(!»)  I ’roduce  knowledge-base  components  for  use  by  the 
application  projects. 
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modify  the  knowledge  base  and  re-evaluate 
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How  Does  a Standard  Become  a Standard? 

Ms.  Sharon  Kemmerer,  NIST  (kemmerer@cme.nist.gov) 


The  summary  for  this  presentation  can  be  found  on  page  53 

2 slides  follow 
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IS  (International  Standard) 

* ISO  - Organization  for  Standardization  ...  all  non-electrotechnical  standards  (IEC  - International 
Electrotechnical  Commission  responsible  for  all  electrotechnical  standards) 


STEP  on  a 


STEP  on  a Page  provides  a 
graphic  summary  of  the  progress  of 
STEP,  Standard  for  the  Ex  change  of 
Product  Model  Data,  the  familiar 
name  for  ISO  10303.  STEP  is 
developed  by  ISO  TC  184)504. 


Status  of  STEP  Parts 

The  twelve  parts  that  comprise  the 
initial  release  ofSTEP  are  circledin 
the  diagram. 

Every  part  shown  in  the  STEP  on 
a P age  has  its  status  shown  beside  it 
The  status  designators  vary  from 
“0”  (the  ISO  preliminary  stage)  to 
“I”  (international  standard- the  most 
advanced  stage  of  standards 
development  and  acceptance).  Parts 
designated  as  “E,  F”  (levels  of  draft 
international  standard)  and  “I”  are 
considered  advanced  enough  to 
allow  software  vendors  to  prepare 
implementations. 


Architecture  of  STEP  and  STEP 

PJIJLP-agfi 

STEP  on  a Page  attempts  to  reflect 
the  STEP  architecture  by  grouping 
the  STEP  parts  into  six  main 
groupings— description  methods, 
integrated  information  resources, 
application  protocols, 

implementation  methods,  and 
conformance  methodology. 

From  an  architectur al  perspective, 
the  description  methods  group  forms 
the  underpinning  of  the  STEP 
standard  This  includes  part  1, 
Overview,  that  also  contains 
definitions  that  are  universal  to  the 
STEP.  Also  in  that  group,  part  11, 
EXPRESS  Language  Reference 
Manual,  describes  the  data-mo deling 
language  that  is  employed  in  STEP. 
Parts  in  the  descriptive-methods 
group  are  numbered  from  1 to  19. 

At  the  next  level  is  the  integrated 
information- 


resources  group,  the  parts  that 
contain  the  actual  STEP  data  models. 
These  data  models  can  be  considered 
the  building  blocks  of  STEP. 
Integated- inform  ation  resources  are 
sub  grouped  into  generic  resources;, 
application  resources,  and 
application- interpreted  constructs  or 
AICs.  Integrated  generic  resources 
are  generic  entities  that  are  used  as 
needed  by  application  protocols 
(APs).  Parts  within  generic  resources 
are  numbered  in  the  40s  and  are  used 
across  the  entire  spectrum  ofSTEP 
APs.  The  inte  g ate  dappli  cation 
resources  contain  entities  that  have 
di^itly  more  context  than  the 
generic  entities.  The  parts  in  the 
integrated  application  resources  are 
numbered  in  the  100s.  Because 
entities  in  the  integrate  dr  e sources 
group  are  shareable  across  the 
applic  ati  on  pr  otoc  ol  s that  ne  e d them, 
they  can  help  enable  AP  inte  g ati  on 
andinteroper  abilily . 

The  500  series  are  application- 
interpreted  constructs,  AICs.  These 
are  reusable  goups  of  information- 
resource  entities  that  make  it  easier 
to  express  identical  semantics  in 
more  than  one  AP. 

At  the  top  level  of  the  STEP 
hierarchy  are  the  more  complex  data 
models  used  to  describe  specific 
product-data  applications.  These 
parts  are  known  as  application 
protocols  and  describe  not  only  what 
data  is  to  be  used  in  describing  a 
product,  but  how  the  data  is  to  be 
used  in  the  model.  The  APs  use  the 
inte  gated  inform  ation  resources  in 
well-defined  combinations  and 
configurations  to  represent  a 
particular  data  model  of  some  phase 
of  product  life.  APs  are  numbered  in 
the  200s.  APs  currently  in  use  are 
the  Explicit  Draughting  AP  201  and 
the  C onfigur  ation  C ontrolled  Design 
AP  203. 


Iarp  lerttcirtatioa  & Conformance 

The  STEP  implementation- 
m ethods  goup,  the  2 0 $ describ  e the 
mapping  from  STEP  formal 
specifications  to  a representation 
used  to  implement  STEP. 

The  conform  anc  e-  te  sting- 

methodology  framework  goup,  the 
30  s,  provides:  information  on 
methods  for  testing  of  software- 
product  conformance  to  the  STEP 
standard,  guidance  for  creating 
abstract-test  suites,  and  the 
responsibilities  of  testing 
laboratories.  The  diagam  shows  that 
part  31,  which  describes  the 
methodology  to  perform 
conformance  testing  has  been 
approved  as  an  international 
standard  The  STEP  standard  is 
unique  in  that  it  places  a very  high 
emphasis  on  testing  and  places  these 
methods  in  the  actual  standard  itself. 


Abstract  Test  Suites 

The  300  series  of  parts,  abstract- 
test  suites,  consists  of  test  data  and 
criteria  that  are  used  to  assess  the 
conformance  of  a STEP  software 
product  to  the  associated  AP.  SC4 
requires  that  eveiy  AP  contain  or  be 
asso  d ate  d with  an  ab  str  act- test  suite. 
The  numbers  assigied  to  ATSs 
exceed  the  AP  numb ers  by  exactly 
100.  Therefore,  ATS  303  applies  to 
AP203. 

ooOO  oo 


STEP  on  a Page  was  conceived 
and  implemented  by  Jim  Nell, 
National  Institute  of  Standards  and 
Technology. 
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jgnell,  89-Oct  23;  rev  98-Mar- 1 6,  Orign:  ISO  10303  Editing  Committee 


ISO  TC184  SC4 


STEP  on  a Page 


ISO  10303 


SKmsjaiiainirsBiOTjiiaiiaiEii! 


I 201  Explicit  draughting  (W)* 

I 202  Associative  draughting  (C) 

I 203  Configurati on- controlled  design  (C) 

C 204  Mechanical  design  using  boundary  ret 
|C  205  Mechanical  design  using  surface  rep  r 
iBX  206  Mechanical  design  using  wireframe  ( 

|E  207  Sheet  metal  die  planning  and  design  (C) 

W208  Life- cycle  product  change  process(W) 

C 209  Compos  & metal  struct,  anal,  & related  den(W) 
C 210  Electronic  P-C  assy:  product-  design  data  (w) 


X 211 
C 212 
E 213 
C 214 
W215 
W216 
W217 
W218 
X 219 
O 220 


Electronic  P-C  assy  test,  diag  & remanuf(W) 
Electrotechnical  design  and  installation  (W) 

Num  contr  (NC)  process  plans  for  m aclvd  parts  (W) 
C ore  data  for  autom otive  me ch  dgn  proce sses  (W) 
Ship  arrangements  (W) 

Ship  moulded  forms  (W) 

Ship  piping  (W) 

Ship  structures  (W) 

Dim  ension  inspection  (X) 

Printed-circuit  assemblies:  mf  g planning  (O) 


C 221  Process  plant  functional  data&  itsschem  rep(W) 
W222  Design-manuf  for  composite  structures  (W) 
W223  Exc  of  dgn  & mfg  product  info  for  cast  parts  (W) 
E 224  Mech  parts  def  far  p pig  using  mach’n’g  feat  (W) 
E 225  Structural  bldg  elem  using  explicit  shape  rep  (w) 

W226  Ship’s  mechanical  systems  (W) 

E 227  Plant  spatial  configuration  (W) 

O 228  Building  services:  HV  AC  (O) 

W229  Forged  parts  (Vi^ 

W230  Building  structural  frame:  steelwork  (W) 

W 231  Process- engineering  data  (W) 

W232  Technical  data  packaging:  core  info  & exch  (W) 
O N eutr  al  opti  c al-  data-  interchange  f orm  at  (O) 

O Product  life- cycle  support— NATO  (O) 

O SG  ML  and  industn  al  data  (O) 


;H5«: 


M 


E,  F,  I safe  to 
implement 

*W  = status  of 
separate 
abstract  test 
state,  e.g. 

ATS  3xx=W 


INTEGRATED-APPLICATION  RESOURCES 

I 101  Draughting 

X 102  Ship  structures 

X 103  E/E  connectivity 

C 104  Finite  element  analysis 

I 105  Kinematics 

W 106  Building  core  model 

A 107  Engineering  anal  core 

INTEGRATED-GENERIC  RESOURCES 

I 41  Fund  of  prdct  descr  & spt(ed2=A) 
I 42  G eom  & topd  rep  (Amd  1 =W) 

I 43  Repres  specialization(ed2=A) 

I 44  Product  struct  config(ed  2=  A) 

F 45  Materials 

I 46  V isual  presentation 

F 47  Tolerances 

X 48  Form  features 

F 49  Process  structure  & properties 

APPLICATION-INTERPRETED  CONSTRUCTS 

C 501  Edge-based  wireframe 

C 502  Shell- based  wireframe 

C 503  G eom -bounded  2D  wireframe 

C 504  Draughting  annotation 

C 505  Drawing  structure  & admin. 

C 506  Draughting  elements 

C 507  G eom -bounded  surface 

C 508  N on-manifold  surface 

C 509  Manifold  surface 

C 510  G eom -bounded wireframe 

C 511  Topol-bounded  surface 

C 512  Faceted  B -representation 

C 513  Elementary  B- rep 

C 5 1 4 AdvancedB-rep 

C 5 1 5 C onstructive  solid  geom  etry 

X516  Mechanical- design  context 

C 517  Mech- design  geom  present’ n 

C 518  Mech-design  shaded  presenl’n 
C 5 19  Geom  etric  tolerances 

C 520  Assoc  draughting  elements 

I 2 1 Clear  text  encoding  of  ex  ch  str. 

E 22  Standard  data  access  interface 

E 23  E arly  C++  (binding  for  #22) 

C 24  Late  C (binding  for  #22) 

X 25  Late  FORTRAN 

E 26  IDL  (binding  for  #22) 

>>>?oo 

0-C3-0-™  Q 
to  to  co  ►Q 

: 

nT  ftT  FiT  [ 

eg  to  to  , 

3 s 


Legend:  Part  Status 

O =Preliminary  Stage  (Proposal—  >approve  NP  ballot) 

A =Proposal  Stage  (NP  circulation->NP  approval) 

W=  Preparatory  Stage  (Working  Draft  devel.— >CD  regis) 


C =Committee  Stage  (CD  circulation— >D IS  regis) 

E = Enquiry  Stage  (DIS  circ.— FDIS  circulation) 

F = Approval  Stage  (FDIS  circ-->Int’l  Stdregs) 

1 =PublicationStg(lntT  Std  approved  & published) 
X =Discontinue  d 
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Presentation:  Breakout  Session  # 1 — Industry  Perspective 

Dr.  Michael  Barbieri,  Lockheed  Martin  (MPBarbieri@lmtas.lmco.com) 


The  summary  for  this  presentation  can  be  found  on  page  55 

2 slides*  follow 


These  slides  were  originally  handwritten  and  have  been  retyped. 
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Determine  what  information  should  be  recorded  on  designs  to  cieate 
archive  of  information 
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Presentation:  Breakout  Session  # 3 — Standards  for  Information 
Modeling/Knowledge  Representation 

Dr.  Simon  Szykman  (szykman@cme.nist.gov) 


The  summary  for  this  presentation  can  be  found  on  page  57 

3 slides*  follow 


These  slides  were  originally  handwritten  and  have  been  retyped. 


Standards/Information  Modeling  and 

Knowledge  Representation 


Current  Practices 


■ Use  of  existing  standards 

• Idef,  EXPRESS  and  STEP 

• Some  good  translators  are  available 

• Limited  to  geometric  information 

• Standards  are  used  as  exchange  mechanisms,  not  for 
data  sharing 

• Typical  loss  of  information 

• Database  issues 

• Numerous  barriers  to  use  of  standards 

• STEP  development  is  slow 
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Standards/Information  Modeling  and 

Knowledge  Representation 


Needs  and  Recommendations 


■ Immediate  Needs 

• Parametric  information 

• Tolerances 

• Features 

• Constraints  and  assembly 

■ Priorities 

• DFM  (for  artifact  and  process) 

• Geometric  precision  problems 

• Design  rationale  and  intent 

• Database  issues 

• Integration  issues 

• Design  retrieval/redesign 
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Standards/Information  Modeling  and 

Knowledge  Representation 


■ Long-Term  and  Other  Issues 

• DFM  (for  artifact  and  process) 

• Conceptual  design  issues 

• Representation  of  function,  system  design 

• Multidisciplinary  issues 

• Ontologies  (part/material  libraries) 

• Relating  measurement  data  to  design  and  process 
data 

• Building  architectural  standards 

• Internet  issues 
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Function-Based  Engineering  Part  Retrieval 

Yumi  Iwasaki,  Richard  Fikes,  Adam  Farquhar,  and  Robert  Engelmore 


The  summary  for  this  presentation  can  be  found  on  page  35 
The  slides  for  the  presentation  start  after  page  278 
8 pages  follow 


Function-Based  Engineering  Part  Retrieval 


Yumi  Iwasaki,  Richard  Fikes,  Adam  Farquhar,  and  Robert  Engelmore 

Knowledge  Systems  Laboratory 
Department  of  Computer  Science 
Gates  Bldg.  2A,  m/c  9020 
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Abstract 

The  Internet  provides  dramatic  new 
opportunities  for  gathering  information 
from  multiple,  distributed,  heterogeneous 
information  sources.  However,  this 
distributed  environment  poses  difficult 
technical  problems  for  the  information- 
seeking  client,  including  finding  the 
information  sources  relevant  to  an  interest, 
formulating  questions  in  the  forms  that  the 
sources  understand,  interpreting  the 
retrieved  information,  and  assembling  the 
information  retrieved  from  several  servers 
into  a coherent  answer.  This  paper 
describes  a function-based  approach  to 
address  this  problem  in  the  context  of 
engineering  part  retrieval.  In  particular,  this 
paper  addresses  the  problems  specific  to  the 
task  of  searching  for  device  components  in 
product  catalogs  based  on  a description  of  a 
desired  function.  We  plan  to  implement  the 
proposed  approach  as  part  of  the  general 
information  broker  architecture  being 
developed  at  Knowledge  Systems 
Laboratory. 

1.  Introduction 

Engineers  need  ready  access  to  a broad  range  of 
information  in  order  to  do  their  work,  and 
finding  the  right  information  is  often  cited  as  the 
#1  technical  problem  in  engineering  design.  It  is 
reported  that  designers  in  industry  spend  over 
50%  of  their  time,  retrieving,  organizing  and 
handling  information  [Court,  Culley  et  al.  1993; 
Baya  and  Leifer  1995].  The  figure  is  expected  to 
well  exceed  50%  during  early  stages  of  novel 
design  projects  [Leifer  1995]. 

Designers  need  many  kinds  of  information, 
including  descriptions  and  models  of  previous 
designs  that  satisfy  functional  requirements 
similar  to  those  of  a current  design  task  and  of 
parts  and  devices  available  for  purchase  that  are 


candidate  components  of  a new  design.  The 
designer's  task  of  obtaining  such  information  is 
made  significantly  more  difficult  because  of  the 
multiple  forms  of  descriptive  criteria  used  in 
specifying  the  queries,  including  desired 
structural,  behavioral,  and/or  functional 
characteristics. 

The  amount  of  time  required  to  search  for 
device  components  in  product  catalogs,  even  if 
they  are  computerized,  is  often  prohibitive.  The 
result  is  the  well-known  tendency  for  engineers 
to  reuse  previous  soludons  that  they  are  familiar 
with  and  to  take  advantage  of  the  information 
that  is  on  their  bookshelves  within  arm's  reach. 

Tools  for  automatically  searching  and 
retrieving  information  on  relevant  device 
components  would  be  a powerful  and  welcome 
tool  to  engineers.  The  Internet  provides  dramatic 
new  opportunities  for  developing  such  tools  that 
can  gather  information  from  multiple,  distributed 
sources.  However,  the  task  is  not  easy  for 
several  reasons; 

• The  volume  of  information  is  enormous.  As 
an  example,  the  Thomas  Register  [Thomas 
Publishing  Company]  ^ contains  approximately 
190,000  suppliers  of  parts. 

• The  informadon  is  inherently  distributed.  It 
resides  with  the  producers  of  the  parts  and 
systems  and  is  stored  in  many  forms.  The 
Thomas  Register  provides  the  list  of  suppliers' 
addresses  and  phone  numbers  under  each  class 
of  products  but  not  detailed  information  about 
each  product.  Many  suppliers  also  describe 
their  products  in  separate  "catalog  pages"  in 
the  Thomas  Register,  but  those  pages  are 
essentially  advertisements  and  rarely  include 
the  detailed  product  specifications  needed  by 
an  engineer. 


1 It  is  the  most  commonly  used  reference  on 
engineering  products  and  suppliers. 
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• No  single  taxonomy  effectively  covers  the 
majority  of  intended  applications.  For 
example,  an  engineer  might  need  a mechanism 
that  will  convert  rotary  to  linear  motion  with 
torque  around  one  Newton-meter  and  length  of 
travel  around  two  meters.  Solutions  include 
rack-and-pinion  gearing,  cable  drives,  shaft 
drives  with  skewed  rollers,  recirculating  ball 
screws,  and  linkages.  No  standard  taxonomy 
would  include  such  a varied  set  of 
mechanisms. 

We  plan  to  use  functional  descriptions  as  well 
as  taxonomic  information  about  parts  and 
systems  to  find  potential  solutions  and  weed  out 
inappropriate  choices.  Our  approach  will  be 
embodied  in  an  information  broker  which  can 
take  advantage  of  explicitly  encoded  ontology  of 
functional  knowledge. 

A competent  broker  of  engineering  products 
can  use  information  such  as  functional, 
behavioral  and  physical  descriptions,  the  context 
of  use,  and  other  general  characteristics 
including  size  and  cost,  to  quickly  find  available 
products  that  best  match  a client's  needs.  A 
broker  should  also  be  able  to  suggest  several 
alternative  methods  to  achieve  a functional  goal 
and  be  able  to  ask  effective  questions  in  helping 
the  client  decide  among  them.  Like  human 
brokers,  effective  computer-based  information 
brokers  must  take  advantage  of  domain-specific 
knowledge,  such  as: 

• The  terminology  used  to  describe  a product, 
including  functional  terminology  as  well  as 
taxonomic  terminology  along  multiple 
dimensions; 

• Typical  ways  for  achieving  functions  (i.e.,  the 
types  of  components  and  the  ways  they  are 
used  to  achieve  certain  functions); 

• Characteristics  of  components  that  are  relevant 
to  achieving  different  functions. 

While  effective  brokering  requires  much 
specialized  domain  knowledge,  building  such 
brokers  as  ad  hoc,  monolithic  applications  for 
each  domain  will  not  scale.  What  is  needed  here 
is  a general  system  architecture  for  information 
brokers  that  can  make  use  of  domain-specific 
ontologies  of  products  and  functions  to  perform 
effective  brokering  in  the  domain. 

In  this  paper,  we  propose  approaches  to  enable 
building  of  such  domain-specific  information 
brokers  of  engineering  components.  In 
particular,  we  propose: 

(1)  An  information  retrieval  scheme  using 
functional  specifications  as  well  as 
taxonomic  information  along  multiple 
dimensions. 


(2)  A methodology  for  codifying  domain- 
specific  functional  and  taxonomic 
ontologies,  and  computational  tools  to  assist 
in  development  and  use  of  such  ontologies. 

2.  Retrieval  Based  on  Function 

A salient  feature  of  the  information  retrieval  task 
in  the  engineering  domain,  not  shared  by  some 
other  domains  (e.g.,  a bibliographic  retrieval 
service  or  a travel  agent),  is  the  importance  of  a 
functional  goal.  A functional  goal  is  the 
specification  of  the  function  that  the  client  hopes 
to  achieve  with  the  component  being  sought. 
The  importance  of  functional  specification  is  not 
an  incidental  fact  about  the  task  but  is  due  to  the 
very  nature  of  the  discipline:  Engineering 
products  are  artifacts  designed  to  achieve  some 
functions  and  engineering  design  is  always 
undertaken  to  meet  some  functional 
specification. 

Thus,  it  is  critical  that  the  client  is  able  to 
specify  the  query  in  terms  of  functions  to  be 
achieved.  Existing  taxonomies,  as  found  in  the 
Thomas  Register  or  PartNet^fCrandall  1993] 
directories,  are  organized  around  the  words  that 
appear  in  the  names  of  devices  and  not  organized 
around  the  functions  that  devices  perform.  Such 
organization  makes  it  difficult  to  retrieve  parts 
based  on  a description  of  what  the  user  is  seeking 
to  achieve  with  the  part  because  (1)  names  may 
not  be  a good  indicator  of  the  function,  and  (2)  it 
requires  one  to  know  the  name  of  the  class  of 
parts  that  can  achieve  the  function  before 
searching  for  them. 

Although  the  name  of  a component  or  a device 
in  some  cases  may  suggest  its  function,  as  in  the 
case  of  "generator"  or  "fastener",  many  names, 
such  as  "gear"  or  "belt",  do  not.  Furthermore, 
relying  on  a name,  such  as  "generator"  to  search 
for  parts  to  achieve  a function  "to  generate"  is 
not  sufficient  for  several  reasons: 

(1)  The  name  of  a class  is  too  general  to  be  a 
functional  specification  by  itself.  For 
example,  the  index  pages  of  the  Thomas 
Register  reveal  that  there  are  over  70  classes 
of  devices  under  "generator".  They  include 


^ PartNet,  developed  at  the  University  of  Utah  , 
is  a project  to  provide  direct,  interactive  on-line 
access  to  parts  catalogs.  This  access  relies  on  the 
Internet  to  provide  an  efficient  communications 
medium  for  transferring  parts  information  from 
vendors  to  customers. 
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everything  from  "Acetylene  Gas  Generator" 
to  "Television  Synchronizing  Generator". 

(2)  The  class  name  is  too  specific  to  be  a 
functional  specification  by  itself.  Many 
devices  that  serve  the  function  of  generating 
something  are  not  called  "generators".  For 
example,  while  an  “alternator”  generates 
electricity  and  a room  “humidifier” 
generates  steam,  neither  of  them  are  indexed 
under  “generator”. 

(3)  The  name  of  a class  does  not  necessarily 
indicate  the  function  implied  by  the  name. 
Despite  the  name,  "generator"  does  not 
necessarily  mean  that  the  function  is  to 
generate.  For  example,  the  function  of 
"tachometer  generator”  is  to  measure 
angular  velocity. 

(4)  There  is  generally  not  a one-to-one 
correspondence  between  a class  in  a 
standard  taxonomy  and  a function.  One 
class  of  devices  can  be  used  to  achieve 
multiple  functions  and  one  function  can  be 
achieved  in  many  different  ways. 

An  even  more  fundamental  problem  is  that  a 
taxonomic  hierarchy,  such  as  employed  by  the 
Thomas  Register  or  PartNet,  is  useless  when 
searching  for  parts  if  one  does  not  already  know 
what  parts  to  use  to  achieve  one's  goal  or  if  one 
is  looking  for  alternative  ways  to  achieve  a 
known  function.  An  effective  broker  must  be 
able  to  understand  the  user's  description  of  what 
he/she  needs  to  achieve,  to  suggest  a variety  of 
methods  for  achieving  it,  and  to  retrieve 
appropriate  parts. 

We  propose  the  general  scheme  shown  in 
Figure  1 for  going  from  a user-provided 
functional  specification  to  available  parts. 


The  functional  specification  schema  represents 
the  functionality  desired  by  the  user.  The  device 
ontology  is  a library  of  "devices"  indexed  by 
function.  Each  type  of  device  specifies  a class  or 
classes  of  components  in  the  information  source 
(e.g.,  the  PartNet  hierarchy  of  parts)  that  is 
commonly  used  to  achieve  the  function.  The 
device  ontology  is  the  body  of  knowledge  that 
allows  mapping  from  the  user-specified 
functionality  to  available  parts.  The  following 
subsections  discuss  representational  and 
inferential  elements  that  are  needed  to  realize 
this  scheme,  but  before  doing  so,  we  describe  our 
view  of  how  the  user  may  provide  the  functional 
specification  through  interactions  with  the 
broker. 

Formally,  the  problem  of  finding  parts  that 
achieve  a function  can  be  viewed  as  a mapping 
from  the  input  functional  specification  to  a set  of 
parts.  If  one  could  expect  the  user  to  start  with  a 
clear  idea  of  the  desired  functionality,  including 
the  constraints  to  be  satisfied  by  the  parts,  the 
task  of  a part  broker  would  reduce  to  simply 
finding  such  mapping.  In  reality,  however,  a 
user  is  not  likely  to  start  with  a complete,  well- 
articulated  functional  specification.  A user  is 
likely  to  start  with  some  high-level  specification 
of  the  desired  functionality,  such  as  "generate 
steam",  and  he/she  may  willy-nilly  provide 
further  constraints  such  as  "portable"  or 
"electrical"  upon  seeing  the  range  of  possibilities 
the  first  query  produces. 

An  important  part  of  helping  the  user  select  a 
part  is  enabling  him/her  to  refine  the  functional 
specification  by  suggesting  additional 
information  that  might  narrow  the  search.  The 
process  of  going  from  functional  specification  to 
parts  should  not  be  expected  to  happen  in  one 


_ . , . Information  sources 

Functional  specification  Device  Ontology  (PartNet,  etc.) 
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Figure  2:  Incremental  functional  specification  refinement-part  retrieval  process 


step  but  proceed  in  many  iterations,  as  shown  in 
Figure  2.  Each  iteration  results  in  a more  refined 
functional  specification,  a smaller  set  of 
candidates,  and  additional  constraints  that  may 
be  solicited  from  the  user  to  narrow  down  the 
search  even  further. 

2.1  Functional  Specification  Schema 

A functional  specification  formalism  should 
satisfy  the  following  requirements  to  be  practical 
for  engineering  part  retrieval: 

(1)  It  should  be  easy  for  a practicing  engineer  to 
write  and  understand  functional 
specifications  without  special  training. 
Therefore,  it  should  use  the  common 
vocabulary  of  the  domain  and  employ  a 
combination  of  ordinary  English  words  and 
domain-specific  vocabulary. 

(2)  It  should  allow  a large  variety  of  functions  to 
be  represented  at  different  levels  of  details. 
It  should  also  allow  a large  variety  of 
information  to  be  included  such  as  cost,  size, 
weight,  context  of  use,  etc.,  depending  on 
the  type  of  function. 

There  have  been  a number  of  proposals  for 
representing  knowledge  of  functions.  One 
important  approach  is  to  specify  function  by 
specifying  the  input/output  behavior  of  a device. 
This  is  simple  and  uniform,  and  may  be  quite 
appropriate  for  some  domains  such  as  digital 
circuits.  In  many  domains,  however,  devices  do 
not  have  well-defined  inputs  or  outputs,  or  if 
they  do,  people  do  not  think  of  them  in  these 
terms.  For  instance,  devices  such  as  fasteners 
and  belts  do  not  have  well-defined  inputs  and 
outputs. 

The  functional  representations  proposed  by 
Sembugamurthy  [Sembugamoorthy  1986]  and 
Iwasaki  [Iwasaki,  Vescovi  et  al.  1995]employ  an 
abstract  specification  of  behavior  and  the 
expected  causal  interactions  among  components. 
These  representations  allow  hierarchical 


decomposition  of  functions  so  that  one  can 
represent  the  function  of  a device  at  many  levels 
of  detail.  The  Causal  Functional  Representation 
Language  (CFRL)  [Iwasaki,  Vescovi  et  al.  1995] 
makes  the  structure  of  a device  and  the  context 
of  its  use  explicit.  Furthermore,  CFRL  has  a 
clear  semantics  defined  by  the  dynamic  behavior 
of  the  device;  as  a consequence,  a functional 
specification  can  be  evaluated  against  an  actual 
(simulated  or  observed)  behavior  of  a device. 
However,  for  the  purpose  of  part  retrieval,  those 
representations  are  likely  to  be  overly  elaborate 
and  cumbersome. 

A more  fundamental  problem,  however,  in 
using  functional  representations  such  as  CFRL  to 
represent  a desired  function  for  the  purpose  of 
part  retrieval  is  that  those  representations  are 
geared  towards  representing  the  functionality 
intended  by  the  designer  of  a device.  On  the  one 
hand,  a CFRL  representation  of  a function  is  an 
abstract  representation  of  the  behavior  the 
designer  expects  a given  structure  to  exhibit  to 
achieve  some  effect,  and,  as  such,  it  includes  a 
specification  of  the  structure  as  well  as  the 
specification  of  the  conditions  under  which  it  is 
to  be  operated.  On  the  other  hand,  what  we  need 
to  represent  for  retrieval  on  functions  is  the 
concept  of  a functionality  that  is  desired  but  not 
yet  associated  with  any  particular  structure  (or 
part).  The  distinction  is  subtle  but  important  for 
our  purpose.  We  will  call  the  former  type  of 
function,  designed  function,  and  the  latter  target 
function  in  the  rest  of  the  document. 

For  our  present  purpose  of  part  retrieval,  we 
propose  to  represent  target  functions  as  a 
combination  of  a verb,  objects,  and  a set  of 
qualifiers.  Since  this  form  of  specifying  a 
function  as  "to  do  something"  is  how  people 
normally  describe  a function  in  English,  it  should 
be  easy  for  an  engineer  to  use  the  form.  We  call 
this  form  a functional  specification  schema. 
Each  functional  specification  schema  represents 
a function  in  the  form  of  "to  do  something",  as  in 
"to  generate  electricity"  and  "to  heat  water". 
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To  do*:  generate 

What?*:  electricity 

Energy  source:  gasoline 
Power  output:  100-200  watts 
Portable?: 

Emergency?: 


To  do*:  convert 

From:  rotary  motion 
to:  linear  motion 

Torque:  100-200  watts 

Length  of  travel: 


Figure  3:  Examples  of  functional  specification  schemata 


Each  schema  has  a required  slot  for  a verb  to 
specify  the  action,  and  zero  or  more  slots  for  the 
objects  to  be  acted  upon.  A schema  also  can 
have  any  number  of  optional  slots  to  elaborate 
the  action  further.  The  exact  set  of  slots  depends 
on  the  verb  and  the  objects. 

Figure  3 shows  some  examples  of  functional 
specification  schemata.  The  slots  marked  with  * 
are  required  slots,  while  other  are  optional  slots. 
The  level  of  indentation  shows  the  dependency 
among  slots.  For  example,  "to  generate"  requires 
the  slot  for  specifying  what  is  to  be  generated. 
"To  convert"  requires  "from”  and  "to".  Finally, 
depending  on  the  content  of  the  action  (to  do) 
and  object  slots  (What?,  From,  and  To),  the 
schema  may  have  any  number  of  additional  slots 
to  further  qualify  the  function. 

Formally,  the  functional  schema  reifies  the 
abstract  concept  of  a target  function.  Without 
reification,  we  can  represent  that  a certain  class 
of  devices  generates  electricity  by  introducing  a 
relation  Generates  and  stating 

Generates( device-instance- 1,  Electricity ). 

This  representation  makes  it  difficult  to  state 
additional  properties  about  the  function  of 
generating  electricity  such  as  the  power  output, 
the  fuel  used,  and  so  on.  These  properties  are 
characteristics  of  this  instance  of  the  generates 
relation.  A function  schema  reifies  the  relation 
and  allows  it  to  be  treated  as  an  individual.  In 
practical  terms,  the  functional  schema  allows  the 
user  to  specify  the  desired  functionality  of  a part 
in  a simple  form  that  is  easy  to  write  and  to 
understand. 

2.2  An  Ontology  of  Function 

The  system  must  have  a vocabulary  of  terms  that 
can  be  used  in  a functional  schema.  An  ontology 
names  and  describes  the  entities  that  are  assumed 
to  exist  in  a domain  and  the  predicates  that  are 
used  to  represent  relationships  among  those 
entities.  In  other  words,  an  ontology  not  only 
provides  a vocabulary  for  representing  and 


communicating  knowledge  about  the  domain  but 
also  makes  explicit  the  relationships  that  are 
assumed  to  hold  among  the  terms  of  that 
vocabulary.  For  functional  schemata,  this  means 
that  the  ontology  defines  the  slots  that  are 
relevant  for  an  action  and  the  vocabulary  that  can 
fill  the  slots. 

Functional  specification  schemata  include  the 
required  slots  for  the  action,  the  objects,  and 
types  of  the  qualifiers.  Thus,  the  ontology  must 
define  the  terms  that  correspond  to  actions  (e.g., 
to  generate,  to  convert,  to  fasten,  to  support, 
etc.),  and  also  the  terms  that  are  objects  of  the 
actions.  In  addition,  functional  specifications 
can  include  a variety  of  qualifying  information 
that  can  help  to  narrow  the  search.  For  example, 
consider  a functional  specification  for  a 
mechanism  that  will  convert  rotary  motion  to 
linear  motion.  The  specification  "to  convert 
rotary  motion  to  linear  motion"  can  be  further 
qualified  by  the  desired  range  for  torques  and 
lengths  of  travel.  Thus,  the  ontology  must  also 
include  a set  of  predicates  and  relations  that  are 
meaningful  for  further  elaborating  the  functional 
specification.  The  vocabulary  of  terms  used  for 
such  qualification  can  be  large,  but  we  conjecture 
that  for  any  given  combination  of  verb  and  object 
(or  objects),  there  is  a fairly  standard  set  of 
qualifications  that  make  sense. 

For  the  purpose  of  part  retrieval  based  on 
function,  it  is  important  for  the  system  not  only 
to  have  a vocabulary  of  words  as  mere  symbols 
attached  to  products  but  also  to  know  their 
meanings  (i.e.,  definitions).  Not  all  products  that 
fit  a desired  qualification  (e.g.,  portable)  may  be 
explicitly  marked  as  such,  and  the  system  must 
be  able  to  judge  whether  a given  candidate  part 
fits  the  qualification  using  the  definition. 

Note  that  the  ontology  must  allow 
polymorphic  definitions  of  terms  to  enable 
context-sensitive  interpretation  of  terms  in 
functional  specifications.  There  are  many  terms, 
whose  meaning  depends  on  the  type  of  function 
or  the  type  of  device  in  question.  For  example. 
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"portable"  is  a term  used  to  describe  many 
different  types  of  devices.  However,  its  meaning 
in  terms  of  the  actual  size,  weight,  etc.,  of  the 
device  varies  depending  on  the  type  of  device.  A 
camera  that  weighs  100  pounds  is  hardly 
portable,  while  an  electric  generator  that  weighs 
the  same  amount  may  be  called  "portable". 
Likewise,  the  meaning  of  the  qualifier 
"emergency"  depends  on  whether  it  is  used  in 
reference  to  electric  generators  or  vehicles. 

2.3  An  Ontology  for  Devices 

Given  a specification  of  a desired  function,  an 
information  broker  must  now  find  parts  that  can 
achieve  the  function.  Our  approach  is  to  build  an 
ontology  of  devices  to  enable  information 
retrieval  from  functions.  A device  ontology 
defines  classes  of  devices  and  their  properties;  it 
will  be  indexed  both  by  function  and  by  a 
standard  taxonomy  such  as  that  found  in  PartNet, 
the  Thomas  Register,  or  the  Federal 
Classification  System  [Defense  Logistics 
Agency].  Here,  we  are  using  the  word  "device” 
in  a broad  sense.  We  define  a device  to  be 
"something  that  has  a function"  [Keuneke  1991; 
Iwasaki,  Vescovi  et  al.  1995].  In  most  cases,  a 
device  in  our  ontology  will  correspond  to  a class 
in  PartNet  or  the  Thomas  Register.  However,  in 
some  cases,  a device  may  consist  of  a 
configuration  of  several  classes  of  parts  that  can 
together  achieve  a function.  In  either  case,  a 
device  in  our  ontology  represents  a design 
fragment,  which  is  an  abstract  design  of  a 
functional  unit  to  be  instantiated  by  the  user's 
choice  of  particular  instances  of  the  class(es). 

In  any  established  engineering  domain,  there 
is  a set  of  standard  engineering  techniques  that 
many  engineers  know  to  achieve  an  often-needed 
function.  For  example,  to  achieve  the  function 
"to  convert  rotary  to  linear  motion  with  torques 
in  the  range  of  one  Newton-meter  and  lengths  of 
travel  about  two  meters",  an  experienced 
engineer  can  list  solutions  including  "rack-and- 
pinion  gearing",  "cable  drives",  "shaft  drives 
with  skewed  rollers",  "recirculating  ball  screws", 
and  "linkages".  We  conjecture  that  the  number 
of  such  techniques  of  typical  functions  is 
relatively  small  (on  the  order  of  10s,  not  100s  per 
function). 

The  devices  in  the  ontology  will  be  indexed 
along  a standard  taxonomic  hierarchy  as  well  as 
functions.  Functional  indexing  is  accomplished 
by  associating  each  device  class  with  one  or 
more  functional  schema  template  to  be  matched 
by  the  user-provided  functional  specification. 
The  template  includes  not  only  the  action  and  the 
set  of  objects  to  be  matched,  but  also  relevant 
constraints  on  the  rest  of  the  specification.  For 


example,  the  device  class  of  "photovoltaic  cells" 
can  match  the  functional  specification  "Generate 
electricity"  but  has  constraints  on  desired  power 
output  and  the  energy  source. 

To  allow  part  retrieval,  each  device  class  also 
has  a pointer  to  a class  in  PartNet  hierarchy. 
There  may  also  be  a set  of  further  constraints  for 
filtering  the  instances  in  the  class.  Thus,  the 
retrieval  process  proceeds  as  follows: 

(1)  Given  a functional  specification  schema  S, 
the  system  retrieves  a set  D of  devices 
whose  template  matches  S. 

(2)  For  each  element  in  D,  the  system  retrieves 
the  set  P of  PartNet  classes  each  with 
associated  filtering  constraints. 

(3)  For  each  element  of  P,  the  system  filters  its 
instances  using  the  filtering  constraints  and 
constraints  from  S.  The  parts  that  remain 
are  presented  to  the  user. 

This  approach  has  the  following  advantages: 

( 1 ) Functional  specification  templates  provide  a 
way  to  organize  devices  into  functional 
taxonomies  with  any  degree  of  specificity. 
In  general,  the  number  of  possible  functional 
specifications  is  very  large,  and  there  is  not 
likely  to  be  a way  to  organize  devices  into  a 
simple  class-subclass  hierarchy.  The 
functional  templates  associated  with  each 
class  provide  a way  to  classify  devices  along 
the  functional  dimension  and  serve  as  a clear 
definition  of  each  class. 

(2)  Having  a device  ontology  of  its  own  distinct 
from  the  information  sources  allows  the 
system  to  retrieve  parts  based  on  functions 
even  if  there  is  no  clear  mapping  from  a 
function  desired  to  a class  of  parts  in  one 
information  source.  Some  functions  may 
even  require  parts  from  totally  separate 
classes  of  parts  or  from  different  information 
sources  (catalogs). 

(3)  The  device  ontology  allows  decomposition 
of  functions.  When  a function  can  be 
decomposed  into  sub-functions,  the  device 
class  representing  the  overall  function  can 
point  to  other  classes  that  achieve  the 
subfunctions.  This  promotes  modularization 
of  the  device  ontology  and  avoids 
duplication  of  information  within  the 
ontology  by  enabling  sharing  of 
subfunctions. 

(4)  The  constraints  that  are  part  of  the  templates 
as  well  as  the  filtering  constraints  directly 
suggest  the  types  of  additional  information 
to  be  solicited  from  the  user  to  refine  the 
functional  specification. 

There  is  a wide  range  of  approaches  one  can  take 
to  this  problem  of  mapping  from  function  to 
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parts  differing  on  the  level  of  difficulty.  The 
simplest  is  to  attach  a functional  specification  to 
each  class  of  parts  in  an  information  source. 
This  approach  does  not  work  well  if  the  parts  in 
the  information  source  are  not  organized  around 
functions,  as  is  typically  the  case.  The  most 
sophisticated  approach  is  to  automatically  design 
a configuration  of  parts  to  achieve  the  function. 
Automatic  design  is  a subject  that  has  been 
researched  extensively  but  that  remains 
impractical  except  in  limited  cases  requiring  only 
parametric  design.  The  approach  proposed  here 
aims  for  a middle  ground  between  the  two 
extremes  that  will  be  most  practical  and  useful 
for  practicing  engineers.  One  can  start  from  a 
basic  set  of  design  fragments,  and  as  the  device 
ontology  grows,  the  information  broker  can 
move  along  the  spectrum  of  sophistication. 

3.  Related  Work 

There  is  a considerable  amount  of  related  work 
in  both  the  areas  of  information  seeking  agents 
and  functional  representation. 

3.1  Information  seeking  agents 

Three  research  efforts  on  information  gathering 
from  heterogeneous  information  sources  are 
closely  related  to  the  information  brokering 
aspects  of  the  work  described  here,  although  they 
do  not  make  use  of  functional  representations. 
These  are:  research  at  ISI  on  the  SIMS  project 
[Knoblock,  Arens  et  al.  1994],  research  at  MCC 
on  the  Carnot  project  [Collet,  Huhns  et  al.  1991], 
and  research  at  AT&T's  Bell  Laboratories  on 
information  gathering  agents  [Levy,  Sagiv  et  al. 
1994],  The  Carnot  project  relies  on  the  large 
common  sense  knowledge  base  of  Cyc  [Lenat 
and  Guha  1990],  assuming  that  it  can  be  used  for 
all  domains.  In  contrast,  we  intend  to  use 
smaller  domain  models  so  that  (1)  it  will  be 
easier  for  the  broker  to  maintain  its  own  small 
domain-dependent  ontology  than  to  incorporate 
its  ontology  into  the  very  large  ontology  used  in 
Cyc,  and  (2)  it  will  be  easier  to  write  articulation 
axioms  relating  the  vocabulary  of  each 
information  source  to  the  relatively  small  broker 
vocabulary  than  to  the  huge  global  vocabulary  of 
Cyc.  The  research  on  SIMS  contributes  most  to 
the  area  of  query  planning.  SIMS  focuses  on 
query  optimization  through  learning  agents.  Its 
agents  learn  efficient  ways  to  access  multiple 
information  sources  for  well-defined  queries  and 
try  to  improve  efficiency  by  caching  frequently 
retrieved  or  difficult  to  retrieve  information.  The 
research  at  AT&T's  Bell  Labs  on  information 
gathering  agents  also  focuses  on  query 


optimization.  Their  main  contribution  is  in 
providing  a method  for  determining  the  minimal 
set  of  the  relevant  information  sources  needed  to 
answer  a given  query. 

The  Information  Brokers  Project  at  the 
Knowledge  Systems  Laboratory  is  also 
developing  technologies  to  enable  a marketplace 
of  network-based  information  brokers  that 
retrieve  information  about  services  and  products 
via  the  Internet  from  multiple  vendor  catalogs 
and  data  bases.  This  approach  to  information 
brokering  does  not  assume  that  clients  are  easily 
able  to  articulate  an  exact  query.  This  is  critical 
in  the  Internet  environment  because  the  pool  of 
clients  and  information  sources  is  potentially 
enormous,  varied,  and  dynamic.  Therefore,  even 
very  sophisticated  clients  will  find  it  impossible 
to  know  the  full  range  of  relevant  information 
sources  and  vocabulary  available.  Clients  also 
may  wish  to  know  about  information  that  is 
relevant  to  their  query  even  though  they  did  not 
explicitly  request  that  information. 
Consequently,  it  is  essential  to  offer  explanations 
to  the  clients.  This  project  differs  from  other 
research  efforts  by  focusing  on  the  difficulties  in 
formulating  queries,  explaining  retrieved 
information,  and  designing  tools  for  developing 
and  maintaining  information  brokers.  As  these 
considerations  are  also  important  for  part 
retrieval,  we  intend  to  make  full  use  of  the 
technologies  developed  by  the  Information 
Brokers  Project. 

3.2  Functional  representation 

There  has  been  significant  previous  work  on  both 
representing  function  and  using  function  to 
reason  about  physical  devices.  CFRL  is  based 
on  the  work  on  Functional  Representation 
[Sembugamoorthy  1986],  and  it  is  a further 
extension  of  the  work  presented  in  [Iwasaki 
1992].  Bradshaw  and  Young  [Bradshaw  and 
Young  1991]  also  represent  the  intended  function 
in  a manner  similar  to  Functional  Representation, 
and  Franke  [Franke  1991]  proposes  a 
representation  of  an  abstract  pattern  on  behavior 
as  the  function  of  a design  modification.  These 
functional  representations  are  inappropriate  for 
part  retrieval  — they  are  geared  towards 
representing  the  designed  functions  and  not 
target  functions.  The  specifications  are  too 
detailed,  and  presume  some  knowledge  of  the 
device  that  achieves  the  function.  For  part 
retrieval,  one  needs  a specification  that  is  much 
simpler  and  that  does  not  presume  knowledge  of 
the  name  or  the  structure  of  the  device,  as  we 
have  proposed  here. 
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4.  Summary  and  Conclusion 

In  this  paper,  we  have  proposed  techniques  for 
addressing  problems  inherent  in  information 
brokering  of  engineering  components.  In 
particular,  we  have  described 

(1)  A representation  formalism  for  functions 
such  that  the  user  can  specify  the  functional 
goals  using  ordinary  vocabulary  of  the 
domain  with  a varying  degree  of  specificity, 
and 

(2)  Techniques  for  relating  functional 
specifications  provided  by  the  user  to  classes 
of  components  and  component 
characteristics  to  allow  parts  retrieval  on 
functions. 

Our  next  task  is  to  actually  implement  an 
information  broker  for  parts.  The 
implementation  will  use  the  general-purpose 
architecture  being  developed  by  the  Information 
Brokers  Project. 

The  applicability  of  the  general  scheme  we 
have  described  in  this  paper  is  not  necessarily 
limited  to  physical  part  retrieval.  Software, 
including  both  pieces  of  code  to  be  embedded  in 
a physical  device  as  well  as  various  types  of 
analysis  programs  needed  during  the  design 
process,  can  also  be  broadly  viewed  as  parts  with 
intended  functionality.  Large  engineering  firms 
have  an  extensive  library  of  simulation  and 
analysis  programs,  which  pose  the  same  kind  of 
retrieval  problems  as  part  catalogs.  In  the  future, 
we  intend  to  investigate  an  extension  of  this 
approach  to  software  domains  as  well. 
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Abstract 

In  this  paper  1 we  describe  one  aspect  of  our  re- 
search in  the  project  called  HIPED,  which  addressed 
the  problem  of  performing  design  of  engineering  de- 
vices by  accessing  heterogeneous  databases.  The  front 
end  of  the  HIPED  system  consisted  of  interactive  KRI- 
TIK,  a multimodal  reasoning  system  that  combined 
case  based  and  model  based  reasoning  to  solve  a design 
problem.  This  paper  focuses  on  the  backend  processing 
where  five  types  of  queries  received  from  the  front  end 
are  evaluated  by  mapping  them  appropriately  using  the 
“facts”  about  the  schemas  of  the  underlying  databases 
and  “rules”  that  establish  the  correspondance  among 
the  data  in  these  databases  in  terms  of  relationships 
such  as  equivalence,  overlap  and  set  containment.  The 
uniqueness  of  our  approach  stems  from  the  fact  that 
the  mapping  process  is  very  forgiving  in  that  the  query 
received  from  the  front  end  is  evaluated  with  respect 
to  a large  number  of  possibilities.  These  possibilities 
are  encoded  in  the  form  of  rules  that  consider  various 
ways  in  which  the  tokens  in  the  given  query  may  match 
relation  names,  attrribute  names,  or  values  in  the  un- 
derlying tables.  The  approach  has  been  implemented 
using  CORAL  deductive  database  system  as  the  rule 
processing  engine. 

1 Introduction 

Heterogeneity  of  databases  is  becoming  a necessary 
factor  to  contend  with  in  the  design  of  new  applica- 
tions because  of  the  proliferation  of  database  man- 
agement systems  that  used  diverse  data  models  over 
the  last  three  decades.  Among  widely  implemented 
data  models  we  have  the  hierarchical,  network,  rela- 
tional and  object  oriented  data  models.  A large  body 
of  work  exists  that  deals  with  the  mapping  of  these 
models  among  one  another  (e.g.  see  the  mapping  of 
models  using  the  entity  relationship  model  as  an  inter- 
mediate model  in  [1]  [3].  While  vendors  are  also  pro- 
viding middleware  solutions  to  draw  data  from  these 
legacy  systems,  the  semantic  problems  of  resolving, 
naming,  scale,  structure  etc.  that  were  pointed  out 
several  years  ago  [5]  [6]  still  remain.  The  purpose  of 
the  present  research  was  to  develop  a technique  to 

1To  appear  in  the  Proceedings  of  International  Symposium 
on  Cooperative  Database  Systems  for  Advanced  Applications, 
Heian  Shrine,  Kyoto,  Japan,  World  Scientific  Press,  1996. 


dealing  with  the  semantic  differences  in  data  by  tak- 
ing a flexible  rule  based  approach.  Another  goal  of 
the  project  was  to  tie  a set  of  heterogeneous  databases 
to  an  “intelligent  front  end  application”  which  would 
make  requests  for  data  without  any  knowledge  of  the 
schemas  of  the  target  databases.  To  limit  the  degree 
of  difficulty  we  assume  that  we  are  dealing  with  data 
in  relational  databases  only.  This  assumption  is  rea- 
sonable in  the  sense  that  of  the  data  is  coming  from  a 
hierarchical  or  a network  DBMS,  we  can  first  convert 
the  schema  to  a relational  one  before  treating  it  for 
purposes  of  integration. 

The  database  integration  problem  we  discuss  here 
is  couched  in  the  context  of  engineering  design  which, 
like  any  other  design  application,  relies  on  extracting 
data  from  existing  databases  containing  material  data, 
components,  existing  designs  etc.  The  exact  context 
and  the  application  scenario  will  be  explained  in  the 
next  section. 

We  assume  that  relevant  data  for  the  design  ap- 
plication is  stored  in  relations  (tables)  whose  schemas 
are  available  at  “design  time”  to  construct  a rule-base. 
It  is  conceivable  that  to  support  large  scale  engineer- 
ing designs,  data  from  a variety  of  databases,  i.e. , from 
multiple  schemas  would  be  required.  To  facilitate  inte- 
gration of  data  among  these  databases  we  assume  that 
the  “correspondances” , i.e.,  the  similarities  and  differ- 
ences among  the  (meaning  of)  attributes  is  encoded 
in  the  form  of  rules.  Furthermore,  for  our  application 
context,  the  front  end  of  HIPED  issues  certain  queries 
looking  for  relevant  design  information.  We  show  in 
this  paper  how  a query  may  have  several  interpreta- 
tions, each  one  of  which  is  encoded  in  the  form  of  rules 
again. 

Because  of  these  two  kinds  of  rules  involved  in  the 
integration  approach  we  have  termed  our  approach 
a rule  based  approach  to  database  integration.  The 
present  approach  is  an  improvement  over  previous  ap- 
proaches where  we  handled  integration  by  using  the 
correspondance  information  to  derive  the  process  [2] 
[6]  [7]  [8]. 

2 Application  Context 

In  this  section  we  will  provide  the  overall  architec- 
ture of  the  HIPED  system  and  point  out  the  need  for 
heterogeneous  database  processing  which  will  be  de- 
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scribed  and  illustrated  in  the  next  two  sections. 

2.1  Overall  Architecture  of  HIPED 

Our  main  objective  in  the  HIPED  project  is  to  build 
and  demonstrate  an  intelligent  interface  to  a set  of 
(possibly  autonomous)  information  sources  including 
structured  databases,  knowledge  bases,  and  unstruc- 
tured data.  The  approach  we  have  selected  involves 
the  development  of  a mediator  which  utilizes  meta- 
knowledge of  the  underlying  information  stores  to  aid 
a user  in  browsing  data  or  to  enable  an  application 
front-end  to  retrieve  specific  relevant  information  for 
problem  solving. 

The  overall  architecture  of  HIPED  is  described  in 
Figure  1.  The  data  is  organized  at  two  levels  namely, 

(1)  the  metadata  repository  : consisting  of  informa- 
tion about  various  databases  and  tables  in  them  and 

(2)  the  actual  data  which  is  distributed  in  various  het- 
erogeneous databases.  This  organization  reduces  the 
data  to  be  dealt  with  at  the  first  level  to  get  to  the 
appropriate  database(s)  and  table(s).  It  also  allows 
heterogeneity  in  the  various  databases  involved.  The 
Querying  Interface  is  as  described  in  section  3.1.  The 
“data”  together  with  its  “wrapper”  forms  a database 
system.  “Wrapper”  simply  defines  the  access  methods 
to  the  data  for  reading  purposes.  A wrapper  can  be  de- 
signed for  each  target  database  management  system. 
A user  query  would  be  translated  into  the  correspond- 
ing query,  as  understood  by  the  corresponding  “wrap- 
per” , for  each  of  the  relevant  tables.  This  query  would 
then  be  routed  to  the  corresponding  database,  that 
contains  this  table.  The  metadata  repository  is  con- 
sulted in  determining  these  relevant  tables  and  finding 
the  corresponding  database.  The  user  would  get  the 
result,  obtained  after  running  the  query  against  the  ta- 
ble through  the  concerned  “Output  Data”  channel  (s). 

2.2  Interactive  KRITIK  Front  End 

We  developed  the  HIPED  architecture  by  assuming 
a frontend  system  called  Interactive  Kritik  [4],  This 
system  is  a multimode  reasoning  system  which  works 
like  a design  assistant  for  the  design  of  devices  such 
as  acid  coolers,  electrical  devices.  In  its  current  form 
the  system  uses  “hard-wired”  knowledge  in  the  form 
of  LISP  data  structures.  The  goal  was  to  extend  the 
capability  of  interactive  Kritik  to  make  it  scalable  to 
real-life  design  problems  by  incorporating  databases 
of  relevant  design  data  as  the  back  end.  We  there- 
fore abstracted  different  forms  of  generic  query  types 
which  would  be  used  as  requests  to  the  back  end.  By 
coupling  an  intelligent  front  end  application  to  a set 
of  heterogeneous  databases,  we  can  thus  extend  the 
scope  of  problem  solving  by  a large  measure.  For  en- 
gineering device  design,  the  above  front  end  generates 
a number  of  requests  for  data  from  the  underlying  de- 
sign databases  such  as  design  prototypes,  properties  of 
devices  and  components,  material  data,  design  speci- 
fications and  tolerances  etc.  For  illustrative  purposes 
we  have  chosen  five  generic  types  of  queries  that  are 
most  commonly  presented  by  the  front  end.  They  will 
be  explained  in  detail  in  the  following  section. 


Querying  Interface 
(to  the  front  end) 


Figure  1:  The  High  Level  View  of  HIPED  back  end 


3 Rule  Based  Approach  to  Database 
Integration 

As  explained  earlier  the  main  contribution  of  this 
research  is  the  use  of  the  two  types  of  rules  to  accom- 
plish access  to  the  underlying  heterogeneous  informa- 
tion sources.  The  first  set  of  rules  deals  with  estab- 
lishing various  types  of  relationships  among  relation 
names  and  among  attribute  names  across  databases. 
The  second  set  deals  with  the  interpretation  of  queries 
from  the  front  end  so  that  various  possible  mappings 
to  the  interface  of  underlying  target  databases  may  be 
considered.  We  will  explain  both  these  types  of  rules 
when  we  discuss  the  generic  queries  and  their  map- 
pings- 

3.1  Five  generic  types  of  queries 

The  user  is  assumed  to  use  this  system  as  an  En- 
gineering Database  for  device  design.  Let  us  limit  the 
application  domain  for  illustrative  purposes.  We  as- 
sume that  during  the  design  process,  he  would  typi- 
cally like  to  find  components  that  satisfy  his  require- 
ments (e.g.  batteries  with  voltage  rating  higher  than 
10V  and  cheaper  than  $10).  Keeping  this  user’s  per- 
spective in  mind,  the  Engineering  data  is  thought  to 
be  made  up  of  various  “Prototypes”.  Each  Proto- 
type has  various  “Properties”.  Each  Property  takes 
up  some  “Value”  for  every  Prototype.  We  can  com- 
pare the  Values  of  various  properties  using  the  rela- 
tions : ==,<,>,<  = ,>=,<>  etc.  The  queries  can 
be  classified  into  the  following  five  generic  types, 

1.  (Prototype  <proto_name>)  : here  the  user 
is  looking  for  all  the  prototypes  identified  by 
“proto_name” . It  is  implicit  that  the  user  wants 
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to  see  the  various  values  for  various  properties 
(attributes)  of  these  prototypes. 

2.  (Property  <prop_name>)  : the  user  is  interested 
in  all  the  prototypes  having  the  specific  Property 
identified  by  “prop_name” . It  is  implicit  that  the 
user  wants  to  see  the  values  taken  by  this  property 
for  the  various  prototypes,  that  would  be  listed. 

3.  (Prototype  <proto_name>) 

(Property  <prop_name>)  : the  user  wants  to  see 
all  the  prototypes  identified  by  “proto_name”  and 
having  property  identified  by  “prop_name”.  It  is 
implicit  that  the  user  also  wants  to  see  the  cor- 
responding value  that  the  property  takes  for  the 
particular  prototype. 

4.  (Prototype  <proto_name>) 

(Property  <prop_name>) 

(Value<value>)  (Rel-op  <op>)  : the  user  is  in- 
terested in  prototypes  identified  by  “protojname” 
having  a property  identified  by  “prop_name”.  In 
addition  to  this  he  wants  only  those  prototypes 
for  which  the  property  takes  a value  which  is  re- 
lated to  the  given  “value”  or  a constant  in  the 
query  by  the  operator  “op”  (i.e.  it  is  equal  to 
“value”  or  greater  than  “value”  etc.) 

5.  (Property  <prop_name>)  (Value  <value>) 
(Rel-op  <op>)  : the  user  is  interested  in  all  the 
prototypes  for  which  the  property  identified  by 
“prop_name”  takes  a value  which  is  related  to  the 
given  “value”  by  the  operator  “op. 

Data  is  distributed  among  various  databases  and 
various  tables  in  each  of  those  databases.  The  only 
assumption  that  we  make  about  any  database  system 
is  that  it  has  an  SQL  access  method.  It  is  a reasonable 
assumption  and  is  made  to  contain  the  complexity  of 
the  problem. 

The  system  needs  to  find  out  which  databases  and 
which  tables  in  these  databases  have  the  relevant  data 
to  answer  a particular  query.  It  then  translates  the 
query  into  a corresponding  SQL  query  for  every  table. 
This  SQL  query  is  run  against  that  table  to  get  an 
answer.  As  we  made  an  assumption  of  a uniform  SQL 
interface  to  all  the  databases,  we  can  simply  translate 
a request  for  data  into  a set  of  SQL  queries  in  each  of 
these  cases. 

3.2  Rules  for  Interpretation  of  Queries 

For  better  understanding  of  the  following  discus- 
sion, let  us  take  up  an  example  query.  Let  the  four 
components  of  the  query  be, 

(Prototype  Battery)  (Property  Voltage) 

(Value  10)  (Relation  ==). 

As  there  can  be  various  tables  with  different  schema, 
we  need  to  run  this  query  with  only  those  tables  that 
might  give  meaningful  results  for  the  query.  We  can 
easily  observe  that  any  of  “Prototype”,  “Battery”, 
“Property”  and  “Voltage”  can  be  a table  or  a column 
of  a table.  The  “Battery”  and  “Voltage”  can  also  be 
values  in  the  columns  (e.g.  those  labeled  as  “Proto- 
type” and  “Property”  respectively).  Of  course  there 
are  a lot  of  dependencies  amongst  these  components 


- e.g.  if  “Prototype”  is  a table  then  “Battery”  has  to 
be  a column  of  this  table.  On  the  other  hand  if  there 
is  a table  called  the  “Battery”,  then  we  are  looking 
for  values  in  the  column  “voltage”  or  “volts”  - so  that 
the  query  would  generate  meaningful  results  with  the 
table.  Now  we  take  up  an  example  query  for  each  of 
the  five  types  listed  above.  For  every  query  we  list  the 
possible  interpretations  according  to  our  scheme. 

1.  (Prototype  Battery).  The  user  typically  means 
that  he  wants  all  the  batteries  with  their  prop- 
erties and  their  corresponding  values.  Hence  we 
will  have  to  run  this  query  against  all  the  tables 
which, 

• are  equivalent  to  “Prototype  Table”  and 
have  a column  equivalent  to  “Battery”  or 

• are  equivalent  to  “Battery  Table” 

• have  a column  equivalent  to  “Prototype” 
(and  only  the  tuples  with  Prototype  as  “Bat- 
tery” would  be  considered). 

if  and  only  if  these  tables  have  columns  equivalent 
to  “Property”  and  “Value”  each. 

2.  (Property  Voltage).  The  user  is  interested  in  list- 
ing all  the  Prototypes  having  “Voltage”  as  their 
one  of  the  Properties.  The  Values  of  these  Proper- 
ties would  also  be  significant  from  his  standpoint. 
Hence  we  consider  all  the  tables  which, 

• are  equivalent  to  “Property  Table”  and  have 
a column  equivalent  to  “Voltage”  or 

• are  equivalent  to  “Voltage  Table” 

• have  a column  equivalent  to  “Property”  (and 
only  the  tuples  with  Property  as  “Voltage” 
would  be  considered). 

if  and  only  if  they  have  “Prototype”  equivalent 
column. 

3.  (Prototype  Battery)  (Property  Voltage).  The 
user  wants  all  the  batteries  with  special  interest 
in  their  voltages.  Hence  we  will  run  the  query 
against  all  the  tables  which, 

• are  equivalent  to  “Prototype  Table”  and 
have  “Battery”,  “Property”  and  “Value” 
equivalent  columns  and  we  would  be  inter- 
ested only  in  the  tuples  having  an  entry  of 
“Voltage”  in  the  “Property”  equivalent  col- 
umn or 

• are  equivalent  to  “Prototype  Table”  and 
have  “Battery” , “Voltage”  equivalent 
columns  or 

• are  equivalent  to  “Battery  Table”  and  have 
“Property”  and  “Value”  equivalent  columns. 
We  would  be  interested  only  in  those  tuples 
having  Property  “Voltage”  or 

• are  equivalent  to  “Battery  Table”  and  have 
a column  equivalent  to  “Voltage”  or 
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• are  equivalent  to  “Property  Table”  and  have 
columns  equivalent  to  “Voltage”,  “Proto- 
type” and  “Value” . We  would  be  interested 
in  tuples  with  Prototype  as  “Battery”. 

• are  equivalent  to  “Property  Table”  and 
have  “Voltage”  and  “Battery”  equivalent 
columns. 

• are  equivalent  to  “Voltage  Tables”  and 
have  “Prototype”  and  “Value”  equivalent 
columns.  We  would  look  for  only  tuples  with 
Prototype  as  “Battery”. 

• are  equivalent  to  “Voltage  Table”  with  “Bat- 
tery” and  “Value”  equivalent  columns. 

• have  “Prototype”  and  “Property”  equivalent 
columns  as  far  as  they  have  “Value”  equiv- 
alent column.  Only  the  tuples  with  Proto- 
type as  “Battery”  and  Property  as  “Voltage” 
would  be  considered. 

4.  (Prototype  Battery)  (Property  Voltage)  (Value 
10)  (Relation  ——)■  Here  the  interest  is  indicated 
in  all  the  batteries  having  Voltage  as  “10”.  The 
query  can  be  run  with  all  the  tables  as  indicated 
as  above  with  an  added  constraint  that  only  those 
tuples  which  have  an  entry  of  “10”  in  the  “Volt- 
age” or  “Value”  column  - whichever  is  applica- 
ble - (Note  the  table  can  have  only  one  of  these 
columns  at  a time)  will  be  considered. 

5.  (Property  Voltage)  (Value  10)  (Relation  ==).  All 
the  Prototypes  having  voltage  of  “10”  are  being 
considered.  Thus  all  the  tables  that, 

• are  equivalent  to  “Property  Table”  and  have 
a column  equivalent  to  “Voltage” 

• are  equivalent  to  “Voltage  Table”  and  have 
a column  equivalent  to  “Value” 

• have  “Property”  and  “Value”  equivalent 
columns  along  with  “Prototype”  column, 
(only  tuples  with  Property  “Voltage”  and 
Value  “10”  would  be  taken  into  considera- 
tion). 

would  be  considered  if  and  only  if  they  have  a 
column  equivalent  to  “Prototype”.  All  the  tu- 
ples with  “Voltage”  or  “Value”  being  10  would 
be  taken  into  account. 

3.3  Rules  to  establish  Data  Correspon- 

dance 

We  need  to  relate  various  attributes  and  tables, 
within  and  across  databases.  The  relationship  could 
be  of  equivalence,  subsumption,  overlap,  disjointness 
or  containment.  The  relationship  between  attributes 
needs  to  be  supplied  by  the  schema  developer,  e.g. 
Attributes  called  “volt”  and  “voltage”  in  different  ta- 
bles are  actually  equivalent.  The  relationship  between 
tables  can  either  be  supplied  or  can  be  deduced  by  the 
relationships  of  their  individual  attributes.  A simple 
deduction  rule  can  be  that  two  tables  are  equivalent  if 
all  their  attributes  are  equivalent. 


4 Use  of  CORAL  for  rule  representa- 
tion and  query  processing 

The  metadata  is  stored  in  the  form  of  CORAL  [10] 
[11]  facts  and  rules.  CORAL  is  a deductive  database 
system  which  stores  data  as  facts  and  rules,  and  allows 
for  that  data  to  be  queried.  By  using  CORAL  the  me- 
diator can  decide  which  database(s)  and  table(s)  are 
useful  in  answering  any  given  query.  In  particular, 
CORAL  is  used  in  deriving  relationships  like  equiva- 
lence; between  attributes,  tables  and  databases.  Any 
creation,  deletion  or  modification  of  a table  results  in  a 
change  in  the  metadata  repository.  This  dynamic  be- 
havior can  be  easily  captured  by  CORAL.  In  essence, 
CORAL  provides  us  with  the  facility  for  database  in- 
tegration through  the  facts  and  rules  specified  about 
tables  and  databases.  However,  this  integration  can  be 
considered  implicit  rather  than  explicit  since  no  global 
conceptual  schema  is  explicitly  formed.  Also  the  C++ 
interface  provided  by  CORAL  makes  writing  general 
purpose  programs  easy. 

We  explain  the  implementation  with  the  help  of 
an  example.  One  more  sample  system  for  a single 
database  environment  is  given  in  Table  5.  Some  sam- 
ple input  queries  and  the  corresponding  output  SQL 
queries  are  shown  in  Tables  6 and  7 respectively. 

4.1  A Simple  Example 

Consider  the  query, 

(Prototype  Battery)  (Property  Voltage) . 

Let  us  assume  that  there  are  two  databases  - dbl  and 
db2.  Let  dbl  have  tables  : Table  1 and  Table  2.  and 


CompNo 

Prototype 

Property 

Value 

B101 

Battery 

Voltage 

10 

MIDI 

Motor 

Voltage 

10 

B110 

Battery 

Voltage 

100 

Bill 

Battery 

Current 

100 

Table  1:  “Components”  Table  in  dbl 

let  db2  have  Table  3 and  Table  4. 

We  observe  that  according  to  the  discussion  in  sec- 
tion 3.2  only  the  tables  in  dbl  would  produce  mean- 
ingful results  with  the  query  under  consideration. 


BatteryNo 

Voltage 

BlOl 

15“ 

B102 

— w~ 

Table  2:  “Battery”  Table  in  dbl 
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BatteryNo 

Current 

BlOl 

15 

B102 

30 

Table  3:  “Battery”  Table  in  db2 


BatteryNo 

Supplier  No 

BlOl 

4567 

B102 

4568 

Table  4:  “Supplier”  Table  in  db2 


4.2  Schema  Representation 

It  is  stored  as  CORAL  facts  and  rules.  The  advan- 
tage of  such  a storage  is  that  we  can  utilize  the  strong 
deductive  power  of  CORAL  (e.g.  deducing  equiva- 
lence of  attributes,  equivalence  of  tables  etc.).  The 
various  components  of  the  repository  are  described  be- 
low. 

• First  we  list  all  the  tables  in  all  the  databases  as 
CORAL  facts  : 


'/,  For  the  first  database,  dbl. 
belongsTo( components ,dbl) . 
belongsTo(battery ,dbl) . 

'/,  For  the  second  database,  db2. 
belongsTo (battery ,db2) . 
belongsTo(supplier ,db2) . 


• Then  we  list  attributes  of  individual  tables  as 
CORAL  facts.  The  first  argument  of  these  pred- 
icates is  the  database  name.  It  is  so  because  the 
same  table  may  have  different  attributes  in  dif- 
ferent databases,  e.g.  the  “battery”  table  in  the 
two  databases  “dbl”  and  “db2”  as  shown  below. 

'/,  for  dbl 

hasAttr ibs (dbl , components , 

[compName , prototype , property .value] ) . 
hasAttribs (dbl .battery, [bName, voltage]  ) . 

'/,  for  db2 

hasAttribs (db2 , battery , [bName , current] ) . 
hasAttribs (db2 , supplier , [bName , sName] ) . 

• We  also  need  facts  to  list  what  attributes  are 
equivalent.  The  equivalence  of  tables  can  be  ei- 
ther given  by  facts  or  can  be  deduced  by  the  rules 


(e.g.  two  tables  with  equivalent  attributes  are 
equivalent).  But  we  do  not  need  them  in  this 
particular  example. 

• To  find  whether  a table  has  a particular  attribute 
in  a given  database  we  define  a CORAL  rule  as, 

module  isAttrib. 
export  isAttrib(bf f ) . 
isAttrib  (Db, Table, Attri) 

hasAttribs (Db, Table, Attribs) , 
iselem  (Attri, Attribs) . 
end_module . 

'/,  Module  ‘ ‘iselem’  ’ is  defined  for  the 
'/.  sake  of  completeness, 
module  iselem, 
export  iselem(bb) . 

®pipelining+ . */,  Solve  in  a 

'/,  top-down  fashion 

iselem(X,  [X|_]). 

iselem(X,  [_ I Z] ) iselem(X,Z). 

end_module . 

4.3  Sample  Query  Mapping  Algorithm 

The  mapping  of  input  requests  into  SQL  queries  is 
done  according  to  the  scheme  suggested  in  section  3.2. 
We  use  the  C++  interface  of  CORAL  for  this  matter. 
In  fact,  an  imperative  interface  (e.g.  in  C)  would  have 
been  enough  for  the  purpose.  We  check  for  the  various 
conditions  given  in  the  scheme  and  generate  the  ap- 
propriate SQL  queries  for  the  existing  tables.  We  run 
through  the  algorithm  for  the  example  query  under 
consideration, 

begin 

For  every  ‘ ‘table’ ’ equivalent  to 
‘ ‘prototype  table’ ’ 

for  every  attribute  equivalent 
to  ‘‘battery’’,  say  attribl 

for  every  attribute  equivalent 
to  ‘‘property,  say  attrib2 
if  ‘‘table’’  has  ‘‘attribl’’ 
as  well  as  ‘‘attrib2’’ 
for  every  attribute 
equivalent  to  ‘‘value’’, 
say  attrib3 

if  ‘‘table’’  has  attrib3 
select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 
WHERE  attrib2  ==  voltage  or 
some  equivalent  value, 
goto  next  table 
for  every  attribute  equivalent 
to  ‘‘voltage’’,  say  attrib4 
if  ‘‘table’’  has  attrib4 
select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 
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For  every  ‘‘table'’  equivalent  to 
‘ ‘battery  table’ ’ 
for  every  attribute  equivalent 
to  ‘‘voltage’’,  say  attribl 
if  ‘‘table’’  has  attribl 

select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 
goto  next  table 

for  every  attribute  equivalent 
to  ‘‘property’’,  say  attrib2 
for  every  attribute  equivalent 
to  ‘‘value’’,  say  attrib3 
if  ‘‘table’’  has  attrib2 
and  attrib3 

select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 
WHERE  attrib2  ==  voltage  or 
some  equivalent  value. 

For  every  ‘‘table’’  equivalent 
to  ‘‘property  table’’ 

for  every  attribute  equivalent 
to  ‘‘voltage,  say  attribl 

for  every  attribute  equivalent 
to  ‘‘prototype’’,  say  attrib2 
if  ‘‘table’’  has  ‘‘attribl’’ 
as  well  as  ‘‘attrib2’’ 
for  every  attribute 
equivalent  to  ‘‘value’’, 
say  attrib3 

if  ‘‘table’’  has  attrib3 
select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 
WHERE  attrib2  ==  battery  or 
some  equivalent  value, 
goto  next  table 

for  every  attribute  equivalent 
to  ‘‘battery,  say  attrib4 
if  ‘‘table’’  has  attrib4 
select  the  corresponding 
database  and  fire  SQL  query, 
SELECT  * FROM  table 

For  every  table  equivalent  to 
‘ ‘voltage  table ’ ’ 

for  every  attribute  equivalent 
to  ‘‘battery’’,  say  attribl 
if  ‘‘table’’  has  attribl 
select  the  corresponding 
database  and  fire  SQL  query, 

SELECT  * FROM  table 
goto  next  table 
for  every  attribute  equivalent 
to  ‘‘prototype’’,  say  attrib2 
for  every  attribute  equivalent 
to  ‘‘value’’,  say  attrib3 
if  ‘‘table’’  has  attrib2 
and  attrib3 

select  the  corresponding 
database  and  fire  SQL  query, 


SELECT  * FROM  table 
WHERE  attrib2  ==  battery  or 
some  equivalent  value. 

For  every  table  having  columns 
equivalent  to  each  of 
prototype , property  and  value 
select  the  corresponding 
database  and  fire  SQL  query 
SELECT  * FROM  table 
WHERE  prototype  equivalent  column 

==  battery  equivalent  value 
AND 

property  equivalent  column 
==  voltage  equivalent  value 

end 

4.4  The  Result 

Let  us  say  that  the  wrapper  of  dbl  can  handle  SQL 
queries.  In  that  case  we  first  select  that  database  and 
then  simply  run  a query, 

SELECT  * 

FROM  components 

WHERE  prototype  ==  ‘‘battery’’ 

AND  property  ==  ‘‘voltage’’ 

against  the  first  (“components”)  table  in  the  database. 
We  take  similar  actions  for  the  other  table  in  (possibly 
various)  databases.  The  other  query  in  this  case  would 
be, 

SELECT  * 

FROM  battery 

again  with  the  same  database  namely,  dbl.  The  result 
is  presented  to  the  user  as  displayed  by  the  correspond- 
ing “wrapper”. 

5 Conclusions  and  Future  Work 

In  this  paper  we  illustrated  the  implementation  of  a 
rule-based  database  integration  scheme  by  considering 
two  types  of  rules  : (1)  Rules  to  establish  the  “corre- 
spondence” among  underlying  component  databases 
and  (2)  Rules  to  interpret  data  requests  in  an  “open- 
ended”  fashion  where  no  knowledge  of  the  component 
database  schemas  is  expected  from  the  application 
front  end.  We  also  described  an  interface  to  hetero- 
geneous databases  in  which  a user  may  directly  ac- 
cess the  back  end  data  by  making  use  of  the  rules  of 
data  correspondance  and  an  SQL-like  syntax  for  the 
queries. 

The  system  makes  an  assumption  that  all  the 
databases  involved  provide  an  SQL  interface.  This 
condition  can  be  relaxed.  In  this  case  we  need  to 
generate  different  queries,  as  understood  by  each  of 
the  databases  involved.  This  work  was  predicated  on 
the  assumption  that  the  data  relevant  to  our  appli- 
cation was  stored  in  relational  tables.  An  extension 
of  the  present  work  involves  relaxing  this  assumption 
and  illustrating  the  utility  of  the  approach  by  actu- 
ally providing  wrappers  for  hierarchical  and  network 
databases  and  sequential  files.  That  would  establish 
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'/,  CORAL  facts 
isTable (battery) . 
hasAttr ibs (battery , 

[bname , voltage , current , life]  ) . 

++++++++  for  the  first  data  request  ++++++ 
SELECT  * FROM  battery; 

SELECT  * FROM  voltage; 

SELECT  * FROM  compTable 

WHERE  prototype  ==  battery 

AND  property  ==  voltage; 

++++++++  for  the  second  data  request  +++++ 
SELECT  * FROM  battery; 

isTable(compTable) . 
has Attr ibs ( compTable , 

[no , prototype , property , value] ) . 

SELECT  * FROM  compTable 

WHERE  prototype  ==  battery 

AND  property  ==  current ; 

++++++++  for  the  third  data  request  ++++++ 

isTable (dummy) . 

hasAttrib (dummy , [prototype .property] ) . 

SELECT  * FROM  prototype 

WHERE  property  ==  rps ; 

SELECT  * FROM  motor 

isTable(prototype) . 
hasAttribs (prototype , 

[motor .property .value] ) . 

WHERE  property  ==  rps ; 

SELECT  * FROM  property 

WHERE  prototype  ==  motor; 

SELECT  * FROM  rps 

isTable(motor) . 

hasAttribs (motor, [property .value]  ) . 

WHERE  prototype  ==  motor; 

SELECT  * FROM  compTable 

WHERE  prototype  ==  motor 

isTable (property) . 
hasAttribs (property , 

[rps , prototype , value] ) . 

AND  property  ==  rps ; 

+++++++  for  the  fourth  data  request  +++++ 
SELECT  * FROM  compTable 

WHERE  prototype  ==  sheet 

isTable(rps ) . 

hasAttribs (rps , [prototype , value] ) . 

AND  property  ==  size; 

isTable(voltage) . 

hasAttribs (voltage, [battery, value]  ) . 

Table  7:  The  corresponding  SQL  queries 

'/,  CORAL  rules 

the  practical  utility  of  the  approach  in  a significant 
way.  The  next  step  would  be  to  work  on  a query 

module  isAttrib. 
export  isAttrib (ff ) . 
isAttrib  (X.Y)  hasAttribs(X.Z) , 

iselem  (Y.Z) . 

end_module . 

optimization  by  introducing  a stage  after  the  query 
interpretation  phase  to  evaluate  possible  orderings  of 
sub  queries  and  cross  subquery  reduction  of  redundant 
processing. 

From  the  engineering  design  standpoint,  the  prob- 
lem horizon  can  be  extended  to  include  additional 

Table  5:  A Single  Database  System 

types  of  design  problems.  The  current  implementa- 
tion can  be  initially  enhanced  by  considering  addi- 
tional types  of  design  queries. 

Currently  only  the  individual  tables  are  checked  to 
see  whether  they  provide  satisfactory  data  to  answer 

prototype  battery  property  voltage 
prototype  battery  property  current 
prototype  motor  property  rps 
prototype  sheet  property  size 

a particular  query.  But  it  is  possible  that  two  or  more 
tables  taken  separately  do  not  have  enough  informa- 
tion to  answer  a query.  At  the  same  time,  when  taken 
together  (e.g.  their  join),  they  provide  data  to  an- 
swer the  query.  Consider  that  there  are  two  tables  - 
which  might  be  in  the  same  database  or  in  different 
databases  - one  with  columns  “Component  Number” 
and  “Prototype”.  The  other  with  columns  “Compo- 
nent Number”  and  “Voltage”.  Then  neither  of  them 
provides  enough  information  for  the  query, 

(Prototype  Battery)  (Property  Voltage) 

But  their  equijoin  with  the  additional  condition  of 

Table  6:  Sample  Input  Queries 

“Prototype  ==  Battery”  for  the  tuples  is  of  interest 
to  us.  The  extended  solution  can  exhaustively  take 
care  of  all  such  cases. 

In  essence,  the  overall  rule  based  approach  appears 
promising  in  the  context  of  Navathe’s  long  standing 
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investigation  of  the  database  integration  problem  [5] 

[6]  [7]  f8]  [9]. 
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